Re: [openstack-dev] The CI issue: “cp: cannot create regular file '/opt/stack/new/bin/etcd': Text file busy

[Chris Smart]

On Tue, 17 Oct 2017, at 14:15, linziw...@itri.org.tw wrote:
> and in the /%24LOG_PATH/logs/devstack-early.txt file,
> it shows
> 2017-10-17 02:49:21.324 | + lib/etcd3:install_etcd3:109:  sudo cp
> /opt/stack/new/devstack/files/etcd-v3.1.10-linux-amd64/etcd
> /opt/stack/new/bin/etcd
> 2017-10-17 02:49:21.330 | cp: cannot create regular file
> '/opt/stack/new/bin/etcd': Text file busy
> 
> Can anyone help me to resolve this issue?
> Why the file is busy???
> 

The file is busy because the etcd binary at /opt/stack/new/bin/etcd is
currently being executed and therefore it cannot be replaced, as it has
an open handler on that file.

You can replicate this locally with a different binary, like this (using
the watch command):

$ cp /usr/bin/watch .
$ ./watch ls &
$ cp /usr/bin/watch .
cp: overwrite './watch'? y
cp: cannot create regular file './watch': Text file busy


Not that this is the right solution, but you can move it and then put
the new file in its place (the etcd will continue to run).

For example:

$ cp /usr/bin/watch .
$ ./watch ls &
$ mv watch watch-old
$ cp /usr/bin/watch .
$ ls watch*
watch  watch-old


So, why is /opt/stack/new/bin/etcd already running on that host?...

-c

__
OpenStack Development Mailing 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] [keystone] specification proposal freeze deadline

[Lance Bragstad]

Hey all,

Sending out a reminder that keystone's specification proposal freeze
deadline is this week. We're still in the process of getting formal
dates merged to the schedule [0], but this is roughly the same time line
we use every release.

Let me know if you have any questions. Thanks!

[0] https://review.openstack.org/#/c/509835/




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

[openstack-dev] The CI issue: “cp: cannot create regular file '/opt/stack/new/bin/etcd': Text file busy

[LinziWang]

Hi all,

When I build the jobs “dsvm-tempest-full” and “dsvm-tempest-my-cinder-driver” 
(which are defined in openstack-dev/ci-sandbox),

the error message shows in /$LOG_PATH/console.html:
+/opt/stack/new/devstack-gate/devstack-vm-gate.sh:main:L753:   
/tmp/ansible/bin/ansible primary -f 5 -i 
/home/jenkins/workspace/dsvm-tempest-full/inventory -m shell -a 'cd 
'\''/opt/stack/new/devstack'\'' && sudo -H -u stack DSTOOLS_VERSION=0.4.0 
stdbuf -oL -eL ./stack.sh 2>&1 executable=/bin/bash'

ERROR: the main setup script run by this job failed - exit code: 2
please look at the relevant log files to determine the root cause
Running devstack worlddump.py
Cleaning up host
this takes 3 - 4 minutes (logs at logs/devstack-gate-cleanup-host.txt.gz)
[WARNING]: No hosts matched, nothing to do
Generating static files at /home/jenkins/workspace/dsvm-tempest-full/logs/ara...
Done.
*** FAILED with status: 2
Build step 'Execute shell' marked build as failure..


and in the /%24LOG_PATH/logs/devstack-early.txt file,
it shows
2017-10-17 02:49:21.324 | + lib/etcd3:install_etcd3:109:  sudo cp 
/opt/stack/new/devstack/files/etcd-v3.1.10-linux-amd64/etcd 
/opt/stack/new/bin/etcd
2017-10-17 02:49:21.330 | cp: cannot create regular file 
'/opt/stack/new/bin/etcd': Text file busy

Can anyone help me to resolve this issue?
Why the file is busy???

Thank you.
Linzi


--
本信件可能包含工研院機密資訊，非指定之收件者，請勿使用或揭露本信件內容，並請銷毀此信件。 This email may contain 
confidential information. Please do not use or disclose it in any way and 
delete it if you are not the intended recipient.
__
OpenStack Development Mailing 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] [forum] Schedule Is Available

[Jimmy McArthur]

Hey all. That’s an issue with some of the formatting we copy/pasta’d to our 
scheduling tool. I’ll review all of them tomorrow to make sure that problem is 
remedied. Apologies for the oversight!!

Jimmy


> On Oct 16, 2017, at 9:28 PM, Amrith Kumar  wrote:
> 
> Mike,
> 
> Thanks for sending this out. Long lines in descriptions of many events
> are not being wrapped, take Rochelle's session "Refstack: OpenStack to
> OPNFV, Vertical, Integrated, Interop" at 3:30pm on Wednesday.
> 
> Any chance the descriptions could be wrapped?
> 
> -amrith
> 
> 
> 
>> On Mon, Oct 16, 2017 at 7:43 PM, Mike Perez  wrote:
>> Hey all,
>> 
>> Thanks to Jimmy McArthur for getting the schedule posted so quickly! Here's 
>> the
>> schedule posted on the Summit site filtering by forum related sessions:
>> 
>> https://www.openstack.org/summit/sydney-2017/summit-schedule/#day=2017-11-06&track_groups=63
>> 
>> Please reply to give corrections.
>> 
>> I will be sending emails to listed moderators to verify there will be someone
>> physically present at the Forum to moderate the session. Thank you!
>> 
>> --
>> Mike Perez
>> 
>> __
>> OpenStack Development Mailing 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] [masakari]Propose changes of the core team

[Rikimaru Honjo]

Oops, sorry, my previous mail didn't contain "[masakari]" tag in title.

On 2017/10/16 11:34, Rikimaru Honjo wrote:

Hi,

On 2017/10/13 18:39, Sam P wrote:

Hi All Masakari Cores,

  I would like to propose following changes to Masakari core team.

Current core team:
Masahito Muroi
Rikimaru Honjo
Sampath Priyankara (samP)
Takashi Kajinami
Toshikazu Ichikawa
Tushar Patil
Yukinori Sagara

(A) Proposed to remove from Core team:
(1) Toshikazu Ichikawa
  He was one of the initial members of the project and did a great work
on design the initial Masakari API and Masakari architecture.
However, he is no longer a active member of the community.
I would like to take this opportunity to thank Toshikazu for his work
on Masakari.

I will vote +1 if Toshikazu agrees this proposal.



(B) Confirm your availability as Core member:
  Following members, please confirm your ability to contribute to
Masakari in Queens and future cycles.
(1) Takashi Kajinami
(2) Masahito Muroi
I understand that you are extremely busy with other tasks or other projects
in OpenStack. If it is difficult for you to contribute to Masakari,
I suggest that you step down from core team for now. In future, if you are
wish to participate again, then we can discuss about reinstate you as a core
member of the team.

(C) Add to new members to core team:
(1) Adam Spiers (Suse)
   I would like to add  Adam to core team. He is the current maintainer
of the openstack-resource-agents and leader of the OpenStack HA team.
Considering his technical knowledge of the subject, and past work he
has done in Masakari and related work[1][2],
I think Adam is one of the best persons we can have in our team.

(2) Kengo Takahara (NTT-TX)
  Kengo has been an active contributor to the Masakari project from Newton
  and heavily contribute to crate masakari-monitors and python-masakariclient
  from scratch [3].

I vote +1 for each persons.
Because I've known their achievements.


All Masakari core members, please respond with your comments and objections.
Please cast your vote on (A) and (C).

[1] 
https://review.openstack.org/#/q/project:openstack/openstack-resource-agents-specs
[2] https://etherpad.openstack.org/p/newton-instance-ha
[3] 
http://stackalytics.com/?project_type=all&release=all&metric=commits&user_id=takahara.kengo@as.ntts.co.jp

--- Regards,
Sampath

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






--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Rikimaru Honjo
E-mail:honjo.rikim...@po.ntt-tx.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] [ptls] Sydney Forum Project Onboarding Rooms

[Jeffrey Zhang]

I am the speaker. Michal couldn't be Sydney this summit.

On Tue, Oct 17, 2017 at 1:05 AM, Kendall Nelson 
wrote:

> Added Kolla to my list. Would the speakers be you and Michal?
>
> -Kendall (diablo_rojo)
>
>
> On Thu, Oct 12, 2017 at 5:51 PM Jeffrey Zhang 
> wrote:
>
>> Hi Kendall,
>>
>> Kolla project would like to have a on-boarding session too.
>>
>> thanks.
>>
>> On Fri, Oct 13, 2017 at 5:58 AM, Kendall Nelson 
>> wrote:
>>
>>> Added Nova to my list with Dan, Melanie, and Ed as speakers.
>>>
>>> Thanks Matt,
>>> -Kendall (diablo_rojo)
>>>
>>> On Thu, Oct 12, 2017 at 2:43 PM Matt Riedemann 
>>> wrote:
>>>
 On 10/9/2017 4:24 PM, Kendall Nelson wrote:
 > Wanted to keep this thread towards the top of inboxes for those I
 > haven't heard from yet.
 >
 > About a 1/4 of the way booked, so there are still slots available!
 >
 > -Kendall (diablo_rojo)

 I've tricked the following people into running a Nova on-boarding room:

 - "Super" Dan Smith 
 - Melanie "Structured Settlement" Witt 
 - Ed "Alternate Hosts" Leafe 

 --

 Thanks,

 Matt

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

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


-- 
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] [forum] Schedule Is Available

[Amrith Kumar]

Mike,

Thanks for sending this out. Long lines in descriptions of many events
are not being wrapped, take Rochelle's session "Refstack: OpenStack to
OPNFV, Vertical, Integrated, Interop" at 3:30pm on Wednesday.

Any chance the descriptions could be wrapped?

-amrith



On Mon, Oct 16, 2017 at 7:43 PM, Mike Perez  wrote:
> Hey all,
>
> Thanks to Jimmy McArthur for getting the schedule posted so quickly! Here's 
> the
> schedule posted on the Summit site filtering by forum related sessions:
>
> https://www.openstack.org/summit/sydney-2017/summit-schedule/#day=2017-11-06&track_groups=63
>
> Please reply to give corrections.
>
> I will be sending emails to listed moderators to verify there will be someone
> physically present at the Forum to moderate the session. Thank you!
>
> --
> Mike Perez
>
> __
> OpenStack Development Mailing 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] [ironic] this week's priorities and subteam reports

[Yeleswarapu, Ramamani]

  - larger single-site: TODO
- larger multi-site: TODO

High Priorities
===

Neutron event processing (vdrok, vsaienk0, sambetts)

- status as of 27 Sep 2017:
- spec at https://review.openstack.org/343684, ready for reviews
- WIP code at https://review.openstack.org/440778

Routed network support (sambetts, vsaienk0, bfournie)
-
- status as of 27 Sep 2017:
- WIP code at https://review.openstack.org/#/c/456235/

Rescue mode (rloo, stendulker, aparnav)
---
- Status as on 16 Oct 2017
- spec: 
http://specs.openstack.org/openstack/ironic-specs/specs/approved/implement-rescue-mode.html
- code: https://review.openstack.org/#/q/topic:bug/1526449+status:open
- ironic side:
- All patches are up-to-date.
- Tempest tests based on standalone ironic is WIP.
- nova side:
- https://blueprints.launchpad.net/nova/+spec/ironic-rescue-mode: 
approved for Queens; waiting for ironic part to be done first
- code patch: https://review.openstack.org/#/c/416487/
- (hshiina 16 Oct 2017) izumi777 posted the nova patch before and 
hshiina is maintaining it now. BP has been approved for Queens.

Clean up deploy interfaces (vdrok)
--
- status as of 27 Sep 2017:
- not started

Zuul v3 jobs in-tree (sambetts, derekh, jlvillal)
-
- status as of 16-Oct 2017:
- Started: https://review.openstack.org/511267

Graphical console interface (pas-ha, vdrok, rpioso)
---
- status as of 27 Sep 2017:
- two specs posted: https://review.openstack.org/#/c/306074/
- need to be cleaned up and revived
- there is nova part here, which has to be approved too

BIOS config framework (dtantsur, yolanda, rpioso)
-
- status as of 09 Oct 2017:
- spec under review: https://review.openstack.org/#/c/496481/
- seems close, more review needed
- rpioso is reviewing it.  Didn't get to it this past week, because of 
upstream work.  Reviewing it 20171016.

Ansible deploy interface (pas-ha, yuiryz)
-
- spec: 
http://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/ansible-deploy-driver.html
- status as of 27 Sep 2017:
- clean up happening while still in ironic-staging-drivers:
- 
https://review.openstack.org/#/q/project:openstack/ironic-staging-drivers+file:%255Eironic_staging_drivers/ansible.-+status:open
- will probably import as it is

Traits support planning (johnthetubaguy, TheJulia, dtantsur)

- status as of 16 Oct 2017:
- WIP spec https://review.openstack.org/#/c/504531/
- discussion: 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/123675.html

OpenStack Priorities


Python 3.5 compatibility (Nisha, Ankit)
---
- Topic: 
https://review.openstack.org/#/q/topic:goal-python35+NOT+project:openstack/governance+NOT+project:openstack/releases
- this include all projects, not only ironic
- please tag all reviews with topic "goal-python35"
other patches for experimental gates are not merging as core reviewers are 
asking to add the python3 builder in running gates instead of duplicating them 
in project-config project. https://review.openstack.org/462487,
https://review.openstack.org/462695, https://review.openstack.org/462701 and 
https://review.openstack.org/462706
- Raised https://review.openstack.org/495766 for testing ironic-inspector 
without swift functionality
- anupn to update the python3 job to build tinyipa with python3
- we need to make the ironic job voting eventually. but we need to check that 
nova, glance and neutron already have voting python 3 jobs, otherwise they may 
break us.

Deploying with Apache and WSGI in CI (vsaienk0)
---
- ironic is mostly finished
- (pas-ha) needs to be rewritten for uWSGI, patches on review 
https://review.openstack.org/#/c/507011/3
- do we have install-guide bits on how to do it?
- inspector is TODO and depends on 
https://review.openstack.org/#/q/topic:bug/1525218

Split away the tempest plugin (jlvillal)

- Proposed patch to create all the patches: https://review.openstack.org/489762
- Current (16-Oct-2017) plan is to wait until we have moved our Zuul job 
configuration in-tree. To make the migration easier.
- jlvillal talked to infra and they suggested we do a batch upload as there are 
about 70 patches to merge in.
- need to port new patches in ironic/ironic-tempest-plugin (jlvillal)
- need to migrate ironic-inspector/ironic-temp

[openstack-dev] [refstack] October 17, 2017 RefStack meeting cancelled

[Chris Hoge]

The October 17, 2017 RefStack meeting is cancelled. Our next team meeting
will be held on October 24, 2017.

-Chris

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

[openstack-dev] [forum] Schedule Is Available

[Mike Perez]

Hey all,

Thanks to Jimmy McArthur for getting the schedule posted so quickly! Here's the
schedule posted on the Summit site filtering by forum related sessions:

https://www.openstack.org/summit/sydney-2017/summit-schedule/#day=2017-11-06&track_groups=63

Please reply to give corrections.

I will be sending emails to listed moderators to verify there will be someone
physically present at the Forum to moderate the session. Thank you!

-- 
Mike Perez


pgp9j7R_QsGGu.pgp
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] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers

[Michał Jastrzębski]

So my 0.02$

Problem with handling Newton goes beyond deployment tools. Yes, it's
popular to use, but if our dependencies (openstack services
themselves) are unmaintained, so should we. If we say "we support
Newton" in deployment tools, we make kind of promise we can't keep. If
for example there is CVE in Nova that affects Newton, there is nothing
we can do about it and our "support" is meaningless.

Not having LTS kind of model was issue for OpenStack operators
forever, but that's not problem we can solve in deployment tools
(although we are often asked for that because our communities are
largely operators and we're arguably closest projects to operators).

I, for one, think we should keep current stable policy, not make
exception for deployment tools, and address this issue across the
board. What Emilien is describing is real issue that hurts operators.

On 16 October 2017 at 15:38, Emilien Macchi  wrote:
> On Mon, Oct 16, 2017 at 4:27 AM, Thierry Carrez  wrote:
>> Emilien Macchi wrote:
>>> [...]
>>> ## Proposal
>>>
>>> Proposal 1: create a new policy that fits for projects like installers.
>>> I kicked-off something here: https://review.openstack.org/#/c/511968/
>>> (open for feedback).
>>> Content can be read here:
>>> http://docs-draft.openstack.org/68/511968/1/check/gate-project-team-guide-docs-ubuntu-xenial/1a5b40e//doc/build/html/stable-branches.html#support-phases
>>> Tag created here: https://review.openstack.org/#/c/511969/ (same,
>>> please review).
>>>
>>> The idea is really to not touch the current stable policy and create a
>>> new one, more "relax" that suits well for projects like installers.
>>>
>>> Proposal 2: change the current policy and be more relax for projects
>>> like installers.
>>> I haven't worked on this proposal while it was something I was
>>> considering doing first, because I realized it could bring confusion
>>> in which projects actually follow the real stable policy and the ones
>>> who have exceptions.
>>> That's why I thought having a dedicated tag would help to separate them.
>>>
>>> Proposal 3: no change anywhere, projects like installer can't claim
>>> stability etiquette (not my best option in my opinion).
>>>
>>> Anyway, feedback is welcome, I'm now listening. If you work on Kolla,
>>> TripleO, OpenStack-Ansible, PuppetOpenStack (or any project who has
>>> this need), please get involved in the review process.
>>
>> My preference goes to proposal 1, however rather than call it "relaxed"
>> I would make it specific to deployment/lifecycle or cycle-trailing
>> projects.
>>
>> Ideally this policy could get adopted by any such project. The
>> discussion started on the review and it's going well, so let's see where
>> it goes :)
>
> Thierry, when I read your comment on Gerrit I understand you prefer to
> amend the existing policy and just make a note for installers (which
> is I think the option #2 that I proposed). Can you please confirm
> that?
> So far I see option #1 has large consensus here, I'll wait for
> Thierry's answer to continue to work on it.
>
> Thanks for the feedback so far!
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers

[Emilien Macchi]

On Mon, Oct 16, 2017 at 4:27 AM, Thierry Carrez  wrote:
> Emilien Macchi wrote:
>> [...]
>> ## Proposal
>>
>> Proposal 1: create a new policy that fits for projects like installers.
>> I kicked-off something here: https://review.openstack.org/#/c/511968/
>> (open for feedback).
>> Content can be read here:
>> http://docs-draft.openstack.org/68/511968/1/check/gate-project-team-guide-docs-ubuntu-xenial/1a5b40e//doc/build/html/stable-branches.html#support-phases
>> Tag created here: https://review.openstack.org/#/c/511969/ (same,
>> please review).
>>
>> The idea is really to not touch the current stable policy and create a
>> new one, more "relax" that suits well for projects like installers.
>>
>> Proposal 2: change the current policy and be more relax for projects
>> like installers.
>> I haven't worked on this proposal while it was something I was
>> considering doing first, because I realized it could bring confusion
>> in which projects actually follow the real stable policy and the ones
>> who have exceptions.
>> That's why I thought having a dedicated tag would help to separate them.
>>
>> Proposal 3: no change anywhere, projects like installer can't claim
>> stability etiquette (not my best option in my opinion).
>>
>> Anyway, feedback is welcome, I'm now listening. If you work on Kolla,
>> TripleO, OpenStack-Ansible, PuppetOpenStack (or any project who has
>> this need), please get involved in the review process.
>
> My preference goes to proposal 1, however rather than call it "relaxed"
> I would make it specific to deployment/lifecycle or cycle-trailing
> projects.
>
> Ideally this policy could get adopted by any such project. The
> discussion started on the review and it's going well, so let's see where
> it goes :)

Thierry, when I read your comment on Gerrit I understand you prefer to
amend the existing policy and just make a note for installers (which
is I think the option #2 that I proposed). Can you please confirm
that?
So far I see option #1 has large consensus here, I'll wait for
Thierry's answer to continue to work on it.

Thanks for the feedback so far!
-- 
Emilien Macchi

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

Re: [openstack-dev] [all][tc] TC Candidates: what does an OpenStack user look like?

[Zane Bitter]

On 14/10/17 11:47, Doug Hellmann wrote:

Excerpts from Zane Bitter's message of 2017-10-13 15:21:14 -0400:

Replying to myself here, to avoid singling anyone in particular out. I
want to rephrase the question, because people are overwhelmingly either
failing to understand or refusing to answer it in the way I intended it.

Most of the candidates are essentially saying that the answer is 'everyone'.

I'm glad that we have such a bunch of next-level geniuses running for
the TC that they are able to analyse the needs of all 7 billion people
and evaluate every decision they make against all of them in real time.
Me, I'm just an ordinary guy who can only hold a few things in his head
at once, so I just try to focus on those and collaborate with people who
have different perspectives to make sure that a range of needs are
covered. This is kind of the founding principle of the Open Source
(note: not Free Software) movement, actually. None of us is as smart as
all of us (present company excepted, apparently). So it's good, but
somewhat surprising that y'all are still here, given that you would be
guaranteed insta-billionaires if you went out and started a proprietary
software company.

All sarcasm aside though, 'everyone' is a BS non-answer. It's the
politician's answer.


Blaming the respondents for answering a imprecisely worded question
in a way other than it was intended? We can do better.


I honestly didn't feel it was an imprecisely worded question - I 
included an example, and carefully defined things such as "By 'users' 
here I mean end-users, the actual consumers of OpenStack APIs". 
Nevertheless, I have no problem admitting that I was wrong. Allowing for 
that possibility was the reason I rephrased the question.



Your original question "Who are _you_ building OpenStack for?" was
much more vague than the rephrasing below that specifically asks
about advocacy.


I agree, reading your and Ildiko's and James's responses it's now clear 
to me that this was the root of the problem. It was too easy to 
interpret this as the entirety of the question, rather than just a glib 
way of summing up the actual question immediately preceding it, the 
paragraph of exposition before that, and the example that followed. I 
regret muddying the waters by tacking it on the end.



Even the rewritten question can be answered
legitimately using several different personas by people with a bit
of experience.  I have worked at a public cloud provider and two
distributors with a wide range of customers, and I use OpenStack
clouds myself. I hope that all of that background feeds into my
contributions.


Yes, that's great. I think most people would agree that there's a 
threshold somewhere between 'several' and 'infinity' beyond which we've 
crossed over into platitudes though.



Not only because engineering trade-offs are a real thing, and some use
cases will *definitely* be excluded in order to better serve others, but
because the average user doesn't exist. If you design for the 'average'
user then you are designing for nobody, because nobody is the average
user. We shouldn't be designing for 'everybody' (aka nobody in
particular), but for a large variety of somebodies.

As an example, look at the Keystone discussion that I linked below.
- If you were designing Keystone for an individual user, you'd might
just have one account per tenant.
- If you were designing Keystone for a team deploying semi-autonomous
apps, you might design a way for multiple agents to authenticate to each
tenant.
- If you were designing Keystone for 'everyone', you might have a matrix
of users, tenants and roles - the most generic solution, right? - and
spend half a decade polishing it without ever realising that individual
users don't need it and teams can't use it.


Or you might conclude that the real problem isn't in the identity
service data model, but in the services that don't yet have an
operation to transfer ownership of resources when a user is
deactivated.


Sure, although note that Keystone itself would have to be one of those 
services - you'd have to be able to transfer ownership of trusts for it 
to work.


Suffice to say that nobody should take my example here as anything more 
than a rationale for the importance of user-centred design.[1] 
Specifically, nobody should take it, or anything else that fits in 3 
sentences, as a prescription for the successful design of an identity 
management service - a topic which is vast, complex, intricate, and at 
times highly unintuitive.


cheers,
Zane.

[1] https://en.wikipedia.org/wiki/User-centered_design

__
OpenStack Development Mailing 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] [Swift] SPDK uses Swift as a target system to support k-v store

[Clay Gerrard]

Sounds interesting!  I'd be *very* interested to see *any* work that's been
done to make use of SPDK functionality for faster or more efficient HTTP ->
rotational media storage.  Couple of thoughts...

1) I think the memcache or redis API would be a better target for SPDK
research than Swift's HTTP blobstore API  - if you're just going for a pure
generic kv interface to a abstract/SSD/NVMe/XPoint storage backend [1]

2) if you wanna see how you might store Swift objects in a generic k/v
store you might consider earlier work to support k/v drives [2]

Good luck, I'm excited to see how you might try to apply SPDK to OpenStack
Swift!

Say Hi to Paul!

-Clay

1. the account/container layer of the Swift API in particular leverages a
lot of query like functionality and i'm not aware of any successful attempt
at API parity on a pure k/v store abstraction.
2. https://github.com/swiftstack/kinetic-swift

On Fri, Oct 13, 2017 at 9:18 PM, We We  wrote:

> Hi, all
>
> I am a newcomer in Swift, I have proposed a proposal for k-v store  in the
> SPDK community. The  proposal has submitted on
> https://trello.com/b/P5xBO7UR/things-to-do, please spare some time to
> visit it. In this proposal, we would like to  uses Swift as a target system
> to support k-v store. Could you please share with me if you have any ideas
> about it. I'd love to hear from your professional thoughts.
>
> Thx，
>
> Helloway
>
>
> __
> OpenStack Development Mailing 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] [telemetry][ceilometer] adding Hanxi Liu as ceilometer core

[gordon chung]

hi,

i'd like to welcome Hanxi Liu as the newest core member of ceilometer 
project[1].

Just want to say thanks for the past contributions, for rep'ing us at 
the PTG, and for being (possibly) the only person on Earth with a 
Telemetry team sticker on their laptop. look forward to more. :)

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

cheers,

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

Re: [openstack-dev] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers

[Steven Dake (stdake)]

Steve,

I can see how #1 might be a problem in general and should be addressed in 
reasonable ways.

For #2, I think your analysis of the tech in use is accurate and if a new 
policy is made it be general yet inclusive enough to permit lifecycle 
management tools to improve and grow.

Regards
-steve

On 10/16/17, 8:57 AM, "Steven Hardy"  wrote:

On Mon, Oct 16, 2017 at 2:33 PM, Steven Dake (stdake)  
wrote:
> Emilien,
>
> I generally thought the stable policy seemed reasonable enough for 
lifecycle management tools.  I’m not sure what specific problems you had in 
TripleO although I did read your review.  Kolla was just tagged with the stable 
policy, and TMK, we haven’t run into trouble yet, although the Kolla project is 
stable and has been following the stable policy for about 18 months.  If the 
requirements are watered down, the tag could potentially be meaningless.  We 
haven’t experienced this specific tag enough to know if it needs some 
refinement for the specific use case of lifecycle management tools.  That said, 
the follows release policy was created to handle the special case of lifecycle 
management tool’s upstream sources not being ready for lifecycle management 
tools to release at one coordinated release time.

We initially felt the policy was reasonable too, but there are a
couple of specific recurring pain points:

1. Services land features which require installer/management tool
updates late in the cycle, or the work to update the configuration
tooling just doesn't happen fast enough during a given cycle.

2. Vendor integrations, similar to (1) but specific to enabling vendor
backends e.g for Neutron etc - the work to enable configuring specific
vendor plugins tends to lag the upstream releases (sometimes
significantly) because most vendors are focussed on consuming the
stable branch releases, not the development/master releases.

In an ideal world the answer would be for everyone working on these
integrations to land the installer (e.g puppet/TripleO/Kolla/...)
patches earlier, but even with the concessions around cycle-trailing
deadlines we're finding that there is ongoing pressure to backport
integrations which (according to stable-maint policy) are strictly
"features" but are actually more integration or enablement of features
which do exist in the version of OpenStack we're deploying.

Several releases ago (before we adopted stable: follows-policy) we
tried to solve this by allowing selected feature backports, but this
was insufficiently well defined (and thus abused) so we need some way
to enable vendor integrations and exposure of new features in the
underlying services, without allowing a backport-everything floodgate
to open ;)

I think one difference between TripleO/Puppet and Kolla here is AFAIK
Kolla has several ways to customize the configuration of deployed
services in a fairly unconstrained way, whereas the openstack puppet
modules and TripleO publish interfaces via a somewhat more static
module and "service plugin" model, which improves discoverability of
features e.g for the TripleO UI but causes a headache when you
discover support for a new vendor Neutron plugin is required well
after the upstream release deadline has passed.

Hope that helps clarify somewhat?

Steve

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


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

Re: [openstack-dev] [nova] Interesting bug when unshelving an instance in an AZ and the AZ is gone

[Chris Friesen]

On 10/16/2017 09:22 AM, Matt Riedemann wrote:


2. Should we null out the instance.availability_zone when it's shelved offloaded
like we do for the instance.host and instance.node attributes? Similarly, we
would not take into account the RequestSpec.availability_zone when scheduling
during unshelve. I tend to prefer this option because once you unshelve offload
an instance, it's no longer associated with a host and therefore no longer
associated with an AZ.


This statement isn't true in the case where the user specifically requested a 
non-default AZ at boot time.



However, is it reasonable to assume that the user doesn't
care that the instance, once unshelved, is no longer in the originally requested
AZ? Probably not a safe assumption.


If they didn't request a non-default AZ then I think we could remove it.


3. When a user unshelves, they can't propose a new AZ (and I don't think we want
to add that capability to the unshelve API). So if the original AZ is gone,
should we automatically remove the RequestSpec.availability_zone when
scheduling? I tend to not like this as it's very implicit and the user could see
the AZ on their instance change before and after unshelve and be confused.


I think allowing the user to specify an AZ on unshelve might be a reasonable 
option.  Or maybe just allow modifying the AZ of a shelved instance without 
unshelving it via a PUT on /servers/{server_id}.



4. We could simply do nothing about this specific bug and assert the behavior is
correct. The user requested an instance in a specific AZ, shelved that instance
and when they wanted to unshelve it, it's no longer available so it fails. The
user would have to delete the instance and create a new instance from the shelve
snapshot image in a new AZ.


I'm inclined to feel that this is operator error.  If they want to delete an AZ 
that has shelved instances then they should talk with their customers and update 
the stored AZ in the DB to a new "valid" one.  (Though currently this would 
require manual DB operations.)


If we implemented Sylvain's spec in #1 above, maybe

we don't have this problem going forward since you couldn't remove/delete an AZ
when there are even shelved offloaded instances still tied to it.


I kind of think it would be okay to disallow deleting AZs with shelved instances 
in them.


Chris

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

Re: [openstack-dev] [all][elections] Voting for the TC Election is now open

[Doug Hellmann]

Excerpts from Kendall Nelson's message of 2017-10-15 00:12:26 +:
> Hello All,
> 
> Voting for the TC Election is now open and will remain open until 23:45
> October 20th, 2017 UTC.
> 
> We are selecting 6 TC members, please rank all candidates in your order of
> preference.
> 
> You are eligible to vote if you are a Foundation individual member[1] that
> also has committed to one of the official programs projects[2] over
> the Ocata-Pike timeframe (September, 2016 23:59 UTC to August 3rd , 2017
> 23:59 UTC or if you are one of the extra-atcs.[3]
> 
> What to do if you don't see the email and have a commit in at least one of
> the official programs projects[2]:
> * check the trash or spam folder of your gerrit Preferred Email address[4],
> in case it went into trash or spam

We've had several reports in #openstack-tc of gmail in particular
treating the voting emails as spam.

Doug

> * wait a bit and check again, in case your email server is a bit slow
> * find the sha of at least one commit from the program project repos[2] and
> email the election officials[1]. If we can confirm that you are entitled to
> vote, we will add you to the voters list and you will be emailed a ballot.
> 
> Our democratic process is important to the health of OpenStack, please
> exercise your right to vote.
> 
> Candidate statements/platforms can be found linked to Candidate names[6].
> 
> Happy voting,
> Thank you,
> 
> -Kendall Nelson (diablo_rojo)
> 
> [1]: http://www.openstack.org/community/members/
> [2]:
> https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=oct-2017-elections
> [3]: Look for the extra-atcs element in [2]
> [4]: Sign into review.openstack.org: Go to Settings > Contact Information.
> Look at the email listed as your Preferred Email. That is where the ballot
> has been sent.
> [5]: http://governance.openstack.org/election/#election-officials
> [6]: http://governance.openstack.org/election/#queens-tc-candidates

__
OpenStack Development Mailing 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] Kernel parameters needed to boot from iscsi

[Julia Kreger]

Greetings Yolanda!

I guess I'm slightly not clear. In fact, I may be slightly even more
confused since we've discussed this directly. Thinking out loud, there are
two different scenarios of booting from iSCSI.

1) Human created/assigned/associated LUN off of a SAN which we want a node
to boot from, and that LUN lives onward as the "storage" for the node.

2) Cinder facilitated LUN off of $something that we want a node to boot
from. This largely would be the logic we added this past cycle to support
either booting via iPXE to iSCSI, or in the case of the iRMC driver, to set
the HBA to boot/attach from specific volumes.

I think your largely bringing up the first case when we speak of booting
from iSCSI. If not, then we technically haven't reached the point where we
are explicitly supporting hardware HBA use, but no time like the present!

Since there are many things here, I think we need to make sure we are
contextually on the same page. If any of this is wrong, please correct me:

* You deploying a partition/filesystem image.
* Ironic is partitioning and executing the installation of grub.
* The scenario where your operating requires the boot loader command line
to be updated with specific arguments.
* Part of the problem is the ramdisk initialization where it is only honors
arguments in your specific case.
* Ironic does not presently provide a mechanism to append standard kernel
arguments outside of netboot. Example from ages ago that many may remember,
having to add ``noapic`` in some cases with a SMP kernel is to be used.

I believe it makes sense to have some sort of mechanism to append to the
default list in this case. There is the ansible deploy driver, but it seems
like that might be overkill for setting boot loader parameters, and Ironic
is explicitly executing grub-isntall.

I think the only reason we've resisted in supporting updating the defaults
file the past is because it would mean explicitly writing data to the grub
defaults file on the filesystem, I suspect our comfort level with
supporting that now may be different. In hindsight, considering we
essentially already support this with netboot but not local boot with a
partition image, I think we should add support for appending default
parameters.

Thoughts?

-Julia


On Mon, Oct 16, 2017 at 2:06 AM, Yolanda Robla Mota 
wrote:

> Hi
> Recently i've been helping some customers in the boot from ISCSI feature.
> So far everything was working, but we had a problem when booting the
> deployment image.
> It needed specifically a flag rd.iscsi.ibft=1 rd.iscsi.firmware=1 in the
> grub commands. But as the generated deployment image doesn't contain these
> flags, ISCSI was not booting properly. For other hardware setups, different
> flags may be needed.
> The solution was to manually execute a virt-customize on the deployment
> image to hardcode these parameters.
> I wonder if we can add some feature in Ironic to support it. We have
> discussed about kernel parameters several times. But at this time, it
> affects ISCSI booting. Not having a way in Ironic to customize these
> parameters forces to manual workarounds.
> So can we reconsider the proposal to add kernel parameters there? It could
> be a settable argument (driver_info/kernel_args), and then the IPA could
> set the parameters properly on the image. Or any other option is welcome.
> What are your thoughts there?
>
> Thanks
>
> --
>
> Yolanda Robla Mota
>
> Principal Software Engineer, RHCE
>
> Red Hat
>
> 
>
> C/Avellana 213
>
> Urb Portugal
>
> yrobl...@redhat.comM: +34605641639
> 
> 
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] containerized undercloud in Queens

[Dan Prince]

On Wed, 2017-10-04 at 15:10 +0200, Dmitry Tantsur wrote:
> (top-posting, as it is not a direct response to a specific line)
> 
> This is your friendly reminder that we're not quite near
> containerized 
> ironic-inspector. The THT for it has probably never been tested at
> all, and the 
> iptables magic we do may simply not be containers-compatible. Milan
> would 
> appreciate any help with his ironic-inspector rework.


I spent the time today to test our (very old) ironic-inspector patch
from Pike.

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

Aside from one tweak I made to run dnsmasq as root (this is how systemd
runs this process as well) the service seems to be working perfectly.
Demo recording of what I did below:

https://asciinema.org/a/wGtvZwE65yoasKrRS8NeGMsrH

Also, just want to re-interate that the t-h-t architecture is also
capable as a baremetal installation tool. While I would like to see
inspector containerized if we really need to run it on baremetal this
architecture would support that fine. It is the same architecture we
use for the overcloud and as such it supports mixing and matching
containers alongside baremetal services.

If that doesn't make sense let me just say that whatever you plan on
doing in Queens to Ironic if you plan on supporting that w/ Puppet on
instack-undercloud I have no doubts about being able to support it in
the architecture I'm proposing we adopt here... whether we run the
service on baremetal or in a container.

Dan

> 
> Dmitry
> 
> On 10/04/2017 03:00 PM, Dan Prince wrote:
> > On Tue, 2017-10-03 at 16:03 -0600, Alex Schultz wrote:
> > > On Tue, Oct 3, 2017 at 2:46 PM, Dan Prince 
> > > wrote:
> > > > 
> > > > 
> > > > On Tue, Oct 3, 2017 at 3:50 PM, Alex Schultz  > > > om>
> > > > wrote:
> > > > > 
> > > > > On Tue, Oct 3, 2017 at 11:12 AM, Dan Prince  > > > > om>
> > > > > wrote:
> > > > > > On Mon, 2017-10-02 at 15:20 -0600, Alex Schultz wrote:
> > > > > > > Hey Dan,
> > > > > > > 
> > > > > > > Thanks for sending out a note about this. I have a few
> > > > > > > questions
> > > > > > > inline.
> > > > > > > 
> > > > > > > On Mon, Oct 2, 2017 at 6:02 AM, Dan Prince  > > > > > > t.co
> > > > > > > m>
> > > > > > > wrote:
> > > > > > > > One of the things the TripleO containers team is
> > > > > > > > planning
> > > > > > > > on
> > > > > > > > tackling
> > > > > > > > in Queens is fully containerizing the undercloud. At
> > > > > > > > the
> > > > > > > > PTG we
> > > > > > > > created
> > > > > > > > an etherpad [1] that contains a list of features that
> > > > > > > > need
> > > > > > > > to be
> > > > > > > > implemented to fully replace instack-undercloud.
> > > > > > > > 
> > > > > > > 
> > > > > > > I know we talked about this at the PTG and I was
> > > > > > > skeptical
> > > > > > > that this
> > > > > > > will land in Queens. With the exception of the
> > > > > > > Container's
> > > > > > > team
> > > > > > > wanting this, I'm not sure there is an actual end user
> > > > > > > who is
> > > > > > > looking
> > > > > > > for the feature so I want to make sure we're not just
> > > > > > > doing
> > > > > > > more work
> > > > > > > because we as developers think it's a good idea.
> > > > > > 
> > > > > > I've heard from several operators that they were actually
> > > > > > surprised we
> > > > > > implemented containers in the Overcloud first. Validating a
> > > > > > new
> > > > > > deployment framework on a single node Undercloud (for
> > > > > > operators) before
> > > > > > overtaking their entire cloud deployment has a lot of merit
> > > > > > to
> > > > > > it IMO.
> > > > > > When you share the same deployment architecture across the
> > > > > > overcloud/undercloud it puts us in a better position to
> > > > > > decide
> > > > > > where to
> > > > > > expose new features to operators first (when creating the
> > > > > > undercloud or
> > > > > > overcloud for example).
> > > > > > 
> > > > > > Also, if you read my email again I've explicitly listed the
> > > > > > "Containers" benefit last. While I think moving the
> > > > > > undercloud
> > > > > > to
> > > > > > containers is a great benefit all by itself this is more of
> > > > > > a
> > > > > > "framework alignment" in TripleO and gets us out of
> > > > > > maintaining
> > > > > > huge
> > > > > > amounts of technical debt. Re-using the same framework for
> > > > > > the
> > > > > > undercloud and overcloud has a lot of merit. It effectively
> > > > > > streamlines
> > > > > > the development process for service developers, and 3rd
> > > > > > parties
> > > > > > wishing
> > > > > > to integrate some of their components on a single node. Why
> > > > > > be
> > > > > > forced
> > > > > > to create a multi-node dev environment if you don't have to
> > > > > > (aren't
> > > > > > using HA for example).
> > > > > > 
> > > > > > Lets be honest. While instack-undercloud helped solve the
> > > > > > old
> > > > > > "seed" VM
> > > > > > issue it was outdated the day it landed upstream. The
> > > > > > e

[openstack-dev] [infra][all] Stable branch jobs in Zuul v3

[James E. Blair]

Hi,

If you have started moving Zuul configuration into your project repos,
please note the following:

  You will probably need to backport at least the "project" stanza to
  stable branches.

Zuul's configuration is global; that includes configuration loaded from
all branches of a project.  So you don't need to copy job definitions
from master to stable (but you can -- if you do, those become branch
variants and can be used to alter the behavior of that job on the stable
branch).

And when projects are defined in special repos we call "config
projects", such as the innovatively named "project-config", the jobs
added to those project-pipelines run on all branches (unless otherwise
specified).  That's why when we put the automatically converted project
definitions in project-config, those jobs generally run on all the
branches.

However, when a project definition appears in-repo, it is generally
assumed that those jobs should only run on that branch.  So the project
definition in master indicates which jobs should run on changes to
master, and the definition in stable/ocata says which jobs run on
changes to ocata.

This means a little more work up-front as you move project definitions
in-repo, but in the long run, it should be a very intuitive workflow.
Imagine when we branch stable/queens: the project definition that
currently appears in master will have a copy in stable/queens.  At that
point, further changes to the jobs which run on master will no longer
affect what jobs run on queens changes.  That's the workflow the system
is designed to make easy.

We have updated the migration documentation in the infra-manual to
mention this:

https://docs.openstack.org/infra/manual/zuulv3.html#stable-branches

Please let me know if you have any questions.

-Jim

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

Re: [openstack-dev] [puppet] Proposing Alfredo Moralejo core on puppet-openstack-integration

[Alfredo Moralejo Alonso]

Great!, Thank you all for those words

On Mon, Oct 16, 2017 at 5:21 PM, Emilien Macchi  wrote:
> sounds good, updating Gerrit permissions now.
>
>
> Thanks all,
>
> On Fri, Oct 13, 2017 at 2:09 PM, Iury Gregory  wrote:
>> +1
>>
>> On Oct 13, 2017 17:13, "Alex Schultz"  wrote:
>>
>> +1 thanks for the great contributions
>>
>> On Fri, Oct 13, 2017 at 11:49 AM, Mohammed Naser 
>> wrote:
>>>
>>>
>>> On Fri, Oct 13, 2017 at 1:21 PM, Emilien Macchi 
>>> wrote:

 Alfredo has been doing an incredible work on maintaining Puppet
 OpenStack CI; by always testing OpenStack from trunk and taking care
 of issues. He has been involved in fixing the actual CI problems in
 OpenStack projects but also maintaining puppet-openstack-integration
 repository in a consistent and solid manner.
 Also, he has an excellent understanding how things work in this
 project and I would like to propose him part of p-o-i maintainers
 (among the rest of the whole core team and also dmsimard).
>>>
>>>
>>> Indeed, Alfredo has helped us a lot by giving assistance from the
>>> packagers
>>> side of things and making sure that they release working packages, and
>>> proposing fixes for issues that block promotion of packages to avoid
>>> breaking our CI.
>>>
>>> +2 from me :)
>>>


 As usual, feel free to vote and give feedback.

 Thanks,
 --
 Emilien Macchi


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

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

Re: [openstack-dev] [ironic] ironic and traits

[John Garbutt]

On 16 October 2017 at 17:55, Eric Fried  wrote:

> * Adding references to the specs: ironic side [1]; nova side [2] (which
> just merged).
>
> * Since Jay is on vacation, I'll tentatively note his vote by proxy [3]
> that ironic should be the source of truth - i.e. option (a).  I think
> the upshot is that it's easier for Ironic to track and resolve conflicts
> than for the virt driver to do so.
>

As I see it, all of these options have Ironic as the source of truth for
Nova.

Driver here is about the Ironic drivers, not Nova virt driver.

 > The downside is obvious - with a lot of deploy templates

> > available it can be a lot of manual work.
>
> * How does option (b) help with this?
>

The operator defines the configuration templates. The driver could then
report traits for any configuration templates that it knows it a given node
can support.

But I suspect a node would have to boot up an image to check if a given set
of RAID or BIOS parameters are valid. Is that correct? I am sure there are
way to cache things that could help somewhat.


> * I suggested a way to maintain the "source" of a trait (operator,
> inspector, etc.) [4] which would help with resolving conflicts.
> However, I agree it would be better to avoid this extra complexity if
> possible.
>

That is basically (b.2).


>
> * This is slightly off topic, but it's related and will eventually need
> to be considered: How are you going to know whether a
> UEFI-capable-but-not-enabled node should have its UEFI mode turned on?
> Are you going to parse the traits specified in the flavor?  (This might
> work for Ironic, but will be tough in the general case.)
>
> [1] https://review.openstack.org/504531


Also the other ironic spec: https://review.openstack.org/#/c/504952


> [2] https://review.openstack.org/507052
> [3]
> https://review.openstack.org/#/c/507052/4/specs/queens/appro
> ved/ironic-traits.rst@88
> [4]
> https://review.openstack.org/#/c/504531/4/specs/approved/nod
> e-traits.rst@196
>
> On 10/16/2017 11:24 AM, Dmitry Tantsur wrote:
> > Hi all,
> >
> > I promised John to dump my thoughts on traits to the ML, so here we go :)
> >
> > I see two roles of traits (or kinds of traits) for bare metal:
> > 1. traits that say what the node can do already (e.g. "the node is
> > doing UEFI boot")
> > 2. traits that say what the node can be *configured* to do (e.g. "the
> node can
> > boot in UEFI mode")
> >
> > This seems confusing, but it's actually very useful. Say, I have a
> flavor that
> > requests UEFI boot via a trait. It will match both the nodes that are
> already in
> > UEFI mode, as well as nodes that can be put in UEFI mode.
> >
> > This idea goes further with deploy templates (new concept we've been
> thinking
> > about). A flavor can request something like CUSTOM_RAID_5, and it will
> match the
> > nodes that already have RAID 5, or, more interestingly, the nodes on
> which we
> > can build RAID 5 before deployment. The UEFI example above can be
> treated in a
> > similar way.
> >
> > This ends up with two sources of knowledge about traits in ironic:
> > 1. Operators setting something they know about hardware ("this node is
> in UEFI
> > mode"),
> > 2. Ironic drivers reporting something they
> >   2.1. know about hardware ("this node is in UEFI mode" - again)
> >   2.2. can do about hardware ("I can put this node in UEFI mode")
> >
> > For case #1 we are planning on a new CRUD API to set/unset traits for a
> node.
> > Case #2 is more interesting. We have two options, I think:
> >
> > a) Operators still set traits on nodes, drivers are simply validating
> them. E.g.
> > an operators sets CUSTOM_RAID_5, and the node's RAID interface checks if
> it is
> > possible to do. The downside is obvious - with a lot of deploy templates
> > available it can be a lot of manual work.
> >
> > b) Drivers report the traits, and they get somehow added to the traits
> provided
> > by an operator. Technically, there are sub-cases again:
> >   b.1) The new traits API returns a union of operator-provided and
> > driver-provided traits
> >   b.2) The new traits API returns only operator-provided traits;
> driver-provided
> > traits are returned e.g. via a new field (node.driver_traits). Then nova
> will
> > have to merge the lists itself.
>

As an alternative, we could enable a configuration template by Resource
Class.
That way its explicit, but you don't have to set it on every node?

I think we would then need a version of (b.1) to report that extra trait up
to Nova, based on the given Resource Class.


> > My personal favorite is the last option: I'd like a clear distinction
> between
> > different "sources" of traits, but I'd also like to reduce manual work
> for
> > operators.
>

I am all for making an operators lives easier, but personally I lean
towards explicitly enabling things, hence my current preference for (a).

I would be tempted to add (b.2) as a second step, after we get (a) working
and tested.

> A valid counter-argument is: what if an oper

[openstack-dev] [ptls] UPDATE: Project Onboarding Rooms

[Kendall Nelson]

Hello Everyone :)

With only a few weeks left before the summit, the Onboarding rooms have
started to be published to the schedule[1].

Monday has been filled with the following teams:

   - Congress
   - Heat
   - Glance
   - Blazar
   - Magnum
   - Keystone
   - Barbican
   - Charms
   - QA
   - Designate
   - TripleO
   - Masakari

Please check to see that you and your co speakers don't have any schedule
collisions. I did my best to check that everyone involved didn't have talks
elsewhere, but to be sure, please check :)

The following teams are on my list but I haven't put them on the schedule
yet.

   - Docs/i18n
   - Nova
   - Infra/Stable
   - Helm (pending TC accepting them as an official project)
   - Kolla
   - Tricircle
   - Cinder
   - Horizon

I plan to get them on the schedule in the next week and a half. Ideally, I
was planning to publish them once I had Tuesday filled to minimize shuffle
if conflicts arose. The same with Wednesday.

*There are still rooms available for the projects not seen on either of the
lists above. If you want space, please let me know ASAP- preferably by
Tuesday October 24th.*

Thanks!

-Kendall Nelson (diablo_rojo)

[1]
https://www.openstack.org/summit/sydney-2017/summit-schedule/global-search?t=project+onboarding
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [docs] sitemap automation suggestions

[Petr Kovar]

As for logging 301s, 302s and 404s and the scope, I don't think we are
interested in checking EOL content for those.

As we are about to approve https://review.openstack.org/#/c/507629/, we
also want everybody to understand broken links found in EOL content won't
be fixed, since no content updates to EOL content will be provided.

Cheers,
pk


On Thu, 5 Oct 2017 22:51:31 -0400 (EDT)
"me...@openstack.org"  wrote:

> Hello all!
> 
> As you may be aware, sitemaps generation for docs.openstack.org is currently 
> done via a manually triggered scrapy process. It currently also scrapes the 
> entirety of docs.openstack.org, making processing slow. In order to improve 
> the efficiency of this process, I would like to propose the following updates 
> to the sitemap generation toolkit:
> * keep track (in logs) of 301s, 302s, and 404s,
> * automatic pull of supported releases,
> * cron-managed automatic updates, and
> * setup of Google Webmaster tools (https://www.google.com/webmasters/) 
> * a few style cleanups
> 
> Beyond this, implementing more targeted crawling would improve the processing 
> speed and scope massively. This is, however, a bit of a complicated matter, 
> as it requires us to decide what, exactly, defines scope relevence, in order 
> to limit the crawl domain.
> 
> These are, of course, only our precursory findings. and we would love to hear 
> some feedback about alternate methods and possible tricky aspects of the 
> suggested changes. What do you think? Let us know!
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [tripleo][networking] Organizing the networking squad

[Harald Jensas]

Include me as well Brent.


//
Harald

On 16 Oct 2017 3:41 p.m., "Saravanan KR"  wrote:

Thanks for initiating Brent. Yes, I would participate in the networking
squad.

Regards,
Saravanan KR

On Mon, Oct 16, 2017 at 6:43 PM, Brent Eagles  wrote:
> Hi,
>
> On Tue, Oct 10, 2017 at 10:55 AM, Brent Eagles  wrote:
>>
>> Hi all,
>>
>> The list of TripleO squads includes a "networking squad". In previous
>> cycles, coordinating outside of IRC and email conversations seemed
>> unnecessary as there were only a few contributors and a small number of
>> initiatives. However, with future container related work, increased
usage of
>> ansible, ongoing efforts like routed networks and NFV, os-net-config
related
>> issues, and the increasing number of backends and networking related
>> services being added to TripleO, the world of TripleO networking seems
>> increasingly busy. I propose that we start organizing properly with
periodic
>> sync-ups and coordinating efforts via etherpad (or similar) as well as
>> reporting into the weekly tripleo meeting.
>>
>> Cheers,
>>
>> Brent
>
>
> This was initially not directed at anyone in particular but I've added
> possible interested parties to this thread in case it gets lost in the
> noise! Please reply if you are interested in participating in the
networking
> squad. Proposed first orders of business are:
>
>  - establish the squad's scope
>  - agree on whether we need a scheduled sync up meeting and if so, sort
out
> a meeting time time
>  - outline initial areas of interest and concern and action items
>
> Cheers,
>
> Brent
>
>

__
OpenStack Development Mailing 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] [tc][election] Question for all candidates in TC election: What will you do if you don't win?

[Emilien Macchi]

On Sun, Oct 15, 2017 at 5:15 AM, Amrith Kumar  wrote:
> Full disclosure, I'm running for election as well. I intend to also
> provide an answer to the question I pose here, one that I've posed
> before on #openstack-tc in an office hours session.
>
> Question 1:
>
> "There are M open slots for the TC and there are N (>>M) candidates
> for those open slots. This is a good problem to have, no doubt.
> Choice, is a good thing, enthusiasm and participation are good things.
>
> But clearly, (N-M) candidates will not be elected.
>
> If you are one of those (N-M) candidates, what then? What do you
> believe you can do if you are not elected to the TC, and what will you
> do? (concrete examples would be good)"

I always plan to work on the same things as usual, I'm not rage quitting :-)
The only thing as a TC member is that you can actually vote in
Governance changes. All the rest is about your influence in our
community, and I already explained what my focus has been until now
and what it would be in the near future.

> Question 2:
>
> "If you are one of the M elected candidates, the N-M candidates who
> were not elected represent a resource?
>
> Would you look to leverage/exploit that resource, and if so, how?
> (concrete examples would be good)"
>
> -amrith
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Emilien Macchi

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

Re: [openstack-dev] [ptls] Sydney Forum Project Onboarding Rooms

[Kendall Nelson]

Added Tricircle to my list :) Should be able to avoid conflicts without too
much issue.

-Kendall (diablo_rojo)

On Thu, Oct 12, 2017 at 6:50 PM joehuang  wrote:

> Hello, Kendall,
>
> Tricircle would like to have an on-boarding session too, if there is
> still time slot left and not conflict with other my three sessions:
> ( Mon 6 , 1:55pm-2:15pm, Tricircle - Project Update; Mon 6 , 1:55pm-
> 2:15pm, Move mission critical application to multi-site, what we learned; Wed
> 8 , 2:05pm-2:15pm Edge Computing (Platform) as a Service powered by
> OpenStack. )
>
> Thank you well in advance.
>
> Best Regards
> Chaoyi Huang (joehuang)
> --
> *From:* Jeffrey Zhang [zhang.lei@gmail.com]
> *Sent:* 13 October 2017 8:50
> *To:* OpenStack Development Mailing List (not for usage questions)
>
> *Subject:* Re: [openstack-dev] [ptls] Sydney Forum Project Onboarding
> Rooms
> Hi Kendall,
>
> Kolla project would like to have a on-boarding session too.
>
> thanks.
>
> On Fri, Oct 13, 2017 at 5:58 AM, Kendall Nelson 
> wrote:
>
>> Added Nova to my list with Dan, Melanie, and Ed as speakers.
>>
>> Thanks Matt,
>> -Kendall (diablo_rojo)
>>
>> On Thu, Oct 12, 2017 at 2:43 PM Matt Riedemann 
>> wrote:
>>
>>> On 10/9/2017 4:24 PM, Kendall Nelson wrote:
>>> > Wanted to keep this thread towards the top of inboxes for those I
>>> > haven't heard from yet.
>>> >
>>> > About a 1/4 of the way booked, so there are still slots available!
>>> >
>>> > -Kendall (diablo_rojo)
>>>
>>> I've tricked the following people into running a Nova on-boarding room:
>>>
>>> - "Super" Dan Smith 
>>> - Melanie "Structured Settlement" Witt 
>>> - Ed "Alternate Hosts" Leafe 
>>>
>>> --
>>>
>>> Thanks,
>>>
>>> Matt
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __
>> OpenStack Development Mailing 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] [ptls] Sydney Forum Project Onboarding Rooms

[Kendall Nelson]

Added Kolla to my list. Would the speakers be you and Michal?

-Kendall (diablo_rojo)

On Thu, Oct 12, 2017 at 5:51 PM Jeffrey Zhang 
wrote:

> Hi Kendall,
>
> Kolla project would like to have a on-boarding session too.
>
> thanks.
>
> On Fri, Oct 13, 2017 at 5:58 AM, Kendall Nelson 
> wrote:
>
>> Added Nova to my list with Dan, Melanie, and Ed as speakers.
>>
>> Thanks Matt,
>> -Kendall (diablo_rojo)
>>
>> On Thu, Oct 12, 2017 at 2:43 PM Matt Riedemann 
>> wrote:
>>
>>> On 10/9/2017 4:24 PM, Kendall Nelson wrote:
>>> > Wanted to keep this thread towards the top of inboxes for those I
>>> > haven't heard from yet.
>>> >
>>> > About a 1/4 of the way booked, so there are still slots available!
>>> >
>>> > -Kendall (diablo_rojo)
>>>
>>> I've tricked the following people into running a Nova on-boarding room:
>>>
>>> - "Super" Dan Smith 
>>> - Melanie "Structured Settlement" Witt 
>>> - Ed "Alternate Hosts" Leafe 
>>>
>>> --
>>>
>>> Thanks,
>>>
>>> Matt
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __
>> OpenStack Development Mailing 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] [ironic] ironic and traits

[Eric Fried]

* Adding references to the specs: ironic side [1]; nova side [2] (which
just merged).

* Since Jay is on vacation, I'll tentatively note his vote by proxy [3]
that ironic should be the source of truth - i.e. option (a).  I think
the upshot is that it's easier for Ironic to track and resolve conflicts
than for the virt driver to do so.

> The downside is obvious - with a lot of deploy templates
> available it can be a lot of manual work.

* How does option (b) help with this?

* I suggested a way to maintain the "source" of a trait (operator,
inspector, etc.) [4] which would help with resolving conflicts.
However, I agree it would be better to avoid this extra complexity if
possible.

* This is slightly off topic, but it's related and will eventually need
to be considered: How are you going to know whether a
UEFI-capable-but-not-enabled node should have its UEFI mode turned on?
Are you going to parse the traits specified in the flavor?  (This might
work for Ironic, but will be tough in the general case.)

[1] https://review.openstack.org/504531
[2] https://review.openstack.org/507052
[3]
https://review.openstack.org/#/c/507052/4/specs/queens/approved/ironic-traits.rst@88
[4]
https://review.openstack.org/#/c/504531/4/specs/approved/node-traits.rst@196

On 10/16/2017 11:24 AM, Dmitry Tantsur wrote:
> Hi all,
> 
> I promised John to dump my thoughts on traits to the ML, so here we go :)
> 
> I see two roles of traits (or kinds of traits) for bare metal:
> 1. traits that say what the node can do already (e.g. "the node is
> doing UEFI boot")
> 2. traits that say what the node can be *configured* to do (e.g. "the node can
> boot in UEFI mode")
> 
> This seems confusing, but it's actually very useful. Say, I have a flavor that
> requests UEFI boot via a trait. It will match both the nodes that are already 
> in
> UEFI mode, as well as nodes that can be put in UEFI mode.
> 
> This idea goes further with deploy templates (new concept we've been thinking
> about). A flavor can request something like CUSTOM_RAID_5, and it will match 
> the
> nodes that already have RAID 5, or, more interestingly, the nodes on which we
> can build RAID 5 before deployment. The UEFI example above can be treated in a
> similar way.
> 
> This ends up with two sources of knowledge about traits in ironic:
> 1. Operators setting something they know about hardware ("this node is in UEFI
> mode"),
> 2. Ironic drivers reporting something they
>   2.1. know about hardware ("this node is in UEFI mode" - again)
>   2.2. can do about hardware ("I can put this node in UEFI mode")
> 
> For case #1 we are planning on a new CRUD API to set/unset traits for a node.
> Case #2 is more interesting. We have two options, I think:
> 
> a) Operators still set traits on nodes, drivers are simply validating them. 
> E.g.
> an operators sets CUSTOM_RAID_5, and the node's RAID interface checks if it is
> possible to do. The downside is obvious - with a lot of deploy templates
> available it can be a lot of manual work.
> 
> b) Drivers report the traits, and they get somehow added to the traits 
> provided
> by an operator. Technically, there are sub-cases again:
>   b.1) The new traits API returns a union of operator-provided and
> driver-provided traits
>   b.2) The new traits API returns only operator-provided traits; 
> driver-provided
> traits are returned e.g. via a new field (node.driver_traits). Then nova will
> have to merge the lists itself.
> 
> My personal favorite is the last option: I'd like a clear distinction between
> different "sources" of traits, but I'd also like to reduce manual work for
> operators.
> 
> A valid counter-argument is: what if an operator wants to override a
> driver-provided trait? E.g. a node can do RAID 5, but I don't want this
> particular node to do it for any reason. I'm not sure if it's a valid case, 
> and
> what to do about it.
> 
> Let me know what you think.
> 
> Dmitry
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

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

[openstack-dev] [neutron] Bug deputy report

[Jakub Libosvar]

Hi all,

I was the bug deputy for the last week and I won't be attending today
the upstream meeting so I'm sending out this report:

There was one critical issue but got attention:
https://bugs.launchpad.net/neutron/+bug/1722967

and just a few bugs that need attention from somebody with broader
knowledge of particular topics. Namely:

https://bugs.launchpad.net/neutron/+bug/1722367 - this one can be either
switched to docs bug or probably closes as it was the configuration issue.

https://bugs.launchpad.net/cloud-archive/+bug/1722946 - I asked for more
info there as it's not clear if the issue is in openvswitch or Neutron code.

https://bugs.launchpad.net/neutron/+bug/1723696 - would be good if Moshe
or somebody from SR-IOV team could have a look to prioritize this bug -
there is already a patch on review.

Cheers,
Jakub


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

Re: [openstack-dev] [nova] Interesting bug when unshelving an instance in an AZ and the AZ is gone

[Matt Riedemann]

On 10/16/2017 11:00 AM, Dean Troyer wrote:

[not having a dog in this hunt, this is what I would expect as a cloud consumer]


Thanks for the user perspective, that's what I'm looking for here, and 
operator perspective of course.




On Mon, Oct 16, 2017 at 10:22 AM, Matt Riedemann  wrote:

- The user creates an instance in a non-default AZ.
- They shelve offload the instance.
- The admin deletes the AZ that the instance was using, for whatever reason.
- The user unshelves the instance which goes back through scheduling and
fails with NoValidHost because the AZ on the original request spec no longer
exists.



1. How reasonable is it for a user to expect in a stable production
environment that AZs are going to be deleted from under them? We actually
have a spec related to this but with AZ renames:


Change happens...


2. Should we null out the instance.availability_zone when it's shelved
offloaded like we do for the instance.host and instance.node attributes?
Similarly, we would not take into account the RequestSpec.availability_zone
when scheduling during unshelve. I tend to prefer this option because once
you unshelve offload an instance, it's no longer associated with a host and
therefore no longer associated with an AZ. However, is it reasonable to
assume that the user doesn't care that the instance, once unshelved, is no
longer in the originally requested AZ? Probably not a safe assumption.


Agreed, unless we keep track that the user specified a default or no
AZ at create.


We do keep track of what the user originally requested, that is this 
RequestSpec object thing I keep referring to.




I think nulling the AZ when the original doesn't exist would be
reasonable from a user standpoint, but I'd feel handcuffed if that
happens and I can not select a new AZ. Or throwing a specific error
and letting the user handle it in #3 below:


At the point of failure, the API has done an RPC cast and returned a 202 
to the user, so the only way to provide a message like this to the user 
would be to check if the original AZ still exists in the API. We could 
do that, it would just be something to be aware of.





3. When a user unshelves, they can't propose a new AZ (and I don't think we
want to add that capability to the unshelve API). So if the original AZ is


Here is my question... if I can specify an AZ on create, why not on
unshelve?  Is it the image location movement under the hood?


I just don't think it's ever come up. The reason I hesitate to add the 
ability to the unshelve API is more or less rooted in my bias toward not 
liking shelve/unshelve in general because of how complicated and 
half-baked it is (we've had a lot of bugs from these APIs, some of which 
are still unresolved). That's not the user's fault though, so one could 
argue that if we're not going to deprecate these APIs, we need to make 
them more robust. We, as developers, also don't have any idea how many 
users are actually using the shelve API, so it's hard to know if we 
should spend any time on improving it.





gone, should we automatically remove the RequestSpec.availability_zone when
scheduling? I tend to not like this as it's very implicit and the user could
see the AZ on their instance change before and after unshelve and be
confused.


Agreed that explicit is better than implicit.


4. We could simply do nothing about this specific bug and assert the
behavior is correct. The user requested an instance in a specific AZ,
shelved that instance and when they wanted to unshelve it, it's no longer
available so it fails. The user would have to delete the instance and create
a new instance from the shelve snapshot image in a new AZ. If we implemented


I do not have the list of things in my head that are preserved in
shelve/unshelve that would be lost in a recreate, but that's where my
worry would come.  Presumably that is why I shelved in the first place
rather than snapshotting the server and removing it.  Depends on the
cost models too, if I lose my grandfathered-in pricing by being forced
to recreate I amy be unhappy.


The volumes and ports remain attached to the shelved instance, only the 
guest on the hypervisor is destroyed. It doesn't change anything about 
quota - you retain quota usage for a shelved instance so you have room 
in your quota to unshelve it later.


From what I can tell, the os-simple-tenant-usage API will still count 
the instance and it's consumed disk/ram/cpu against you even though the 
guest is deleted from the hypervisor while the instance is shelved 
offloaded. So the operator is happy about shelved offloaded instances 
because that means they have more free capacity for new instances and 
moving things, but the user is still getting charged the same, if your 
billing model is based on os-simple-tenant-usage (which Telemetry uses I 
believe).






Sylvain's spec in #1 above, maybe we don't have this problem going forward
since you couldn't remove/delete an AZ when there are even shelved offloa

[openstack-dev] [ironic] summary of the ironic-inspector virtual sprint

[Dmitry Tantsur]

Hi all,

We've had a virtual sprint for ironic-inspector. Most of the time we were
discussing the potential re-architecture of it. Please see
https://etherpad.openstack.org/p/inspector-queens-virtual-ptg for notes and
action items, and https://bluejeans.com/s/5yDpk for the recording.

Dmitry

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

[Dmitry Tantsur]

Hi all,

I promised John to dump my thoughts on traits to the ML, so here we go :)

I see two roles of traits (or kinds of traits) for bare metal:
1. traits that say what the node can do already (e.g. "the node is
doing UEFI boot")
2. traits that say what the node can be *configured* to do (e.g. "the node can
boot in UEFI mode")

This seems confusing, but it's actually very useful. Say, I have a flavor that
requests UEFI boot via a trait. It will match both the nodes that are already in
UEFI mode, as well as nodes that can be put in UEFI mode.

This idea goes further with deploy templates (new concept we've been thinking
about). A flavor can request something like CUSTOM_RAID_5, and it will match the
nodes that already have RAID 5, or, more interestingly, the nodes on which we
can build RAID 5 before deployment. The UEFI example above can be treated in a
similar way.

This ends up with two sources of knowledge about traits in ironic:
1. Operators setting something they know about hardware ("this node is in UEFI
mode"),
2. Ironic drivers reporting something they
  2.1. know about hardware ("this node is in UEFI mode" - again)
  2.2. can do about hardware ("I can put this node in UEFI mode")

For case #1 we are planning on a new CRUD API to set/unset traits for a node.
Case #2 is more interesting. We have two options, I think:

a) Operators still set traits on nodes, drivers are simply validating them. E.g.
an operators sets CUSTOM_RAID_5, and the node's RAID interface checks if it is
possible to do. The downside is obvious - with a lot of deploy templates
available it can be a lot of manual work.

b) Drivers report the traits, and they get somehow added to the traits provided
by an operator. Technically, there are sub-cases again:
  b.1) The new traits API returns a union of operator-provided and
driver-provided traits
  b.2) The new traits API returns only operator-provided traits; driver-provided
traits are returned e.g. via a new field (node.driver_traits). Then nova will
have to merge the lists itself.

My personal favorite is the last option: I'd like a clear distinction between
different "sources" of traits, but I'd also like to reduce manual work for
operators.

A valid counter-argument is: what if an operator wants to override a
driver-provided trait? E.g. a node can do RAID 5, but I don't want this
particular node to do it for any reason. I'm not sure if it's a valid case, and
what to do about it.

Let me know what you think.

Dmitry

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

Re: [openstack-dev] [nova] Interesting bug when unshelving an instance in an AZ and the AZ is gone

[Dean Troyer]

[not having a dog in this hunt, this is what I would expect as a cloud consumer]

On Mon, Oct 16, 2017 at 10:22 AM, Matt Riedemann  wrote:
> - The user creates an instance in a non-default AZ.
> - They shelve offload the instance.
> - The admin deletes the AZ that the instance was using, for whatever reason.
> - The user unshelves the instance which goes back through scheduling and
> fails with NoValidHost because the AZ on the original request spec no longer
> exists.

> 1. How reasonable is it for a user to expect in a stable production
> environment that AZs are going to be deleted from under them? We actually
> have a spec related to this but with AZ renames:

Change happens...

> 2. Should we null out the instance.availability_zone when it's shelved
> offloaded like we do for the instance.host and instance.node attributes?
> Similarly, we would not take into account the RequestSpec.availability_zone
> when scheduling during unshelve. I tend to prefer this option because once
> you unshelve offload an instance, it's no longer associated with a host and
> therefore no longer associated with an AZ. However, is it reasonable to
> assume that the user doesn't care that the instance, once unshelved, is no
> longer in the originally requested AZ? Probably not a safe assumption.

Agreed, unless we keep track that the user specified a default or no
AZ at create.

I think nulling the AZ when the original doesn't exist would be
reasonable from a user standpoint, but I'd feel handcuffed if that
happens and I can not select a new AZ. Or throwing a specific error
and letting the user handle it in #3 below:

> 3. When a user unshelves, they can't propose a new AZ (and I don't think we
> want to add that capability to the unshelve API). So if the original AZ is

Here is my question... if I can specify an AZ on create, why not on
unshelve?  Is it the image location movement under the hood?

> gone, should we automatically remove the RequestSpec.availability_zone when
> scheduling? I tend to not like this as it's very implicit and the user could
> see the AZ on their instance change before and after unshelve and be
> confused.

Agreed that explicit is better than implicit.

> 4. We could simply do nothing about this specific bug and assert the
> behavior is correct. The user requested an instance in a specific AZ,
> shelved that instance and when they wanted to unshelve it, it's no longer
> available so it fails. The user would have to delete the instance and create
> a new instance from the shelve snapshot image in a new AZ. If we implemented

I do not have the list of things in my head that are preserved in
shelve/unshelve that would be lost in a recreate, but that's where my
worry would come.  Presumably that is why I shelved in the first place
rather than snapshotting the server and removing it.  Depends on the
cost models too, if I lose my grandfathered-in pricing by being forced
to recreate I amy be unhappy.


> Sylvain's spec in #1 above, maybe we don't have this problem going forward
> since you couldn't remove/delete an AZ when there are even shelved offloaded
> instances still tied to it.

As a user I probably do not mind this, as an operator I'd likely be unhappy.

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] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers

[Steven Hardy]

On Mon, Oct 16, 2017 at 2:33 PM, Steven Dake (stdake)  wrote:
> Emilien,
>
> I generally thought the stable policy seemed reasonable enough for lifecycle 
> management tools.  I’m not sure what specific problems you had in TripleO 
> although I did read your review.  Kolla was just tagged with the stable 
> policy, and TMK, we haven’t run into trouble yet, although the Kolla project 
> is stable and has been following the stable policy for about 18 months.  If 
> the requirements are watered down, the tag could potentially be meaningless.  
> We haven’t experienced this specific tag enough to know if it needs some 
> refinement for the specific use case of lifecycle management tools.  That 
> said, the follows release policy was created to handle the special case of 
> lifecycle management tool’s upstream sources not being ready for lifecycle 
> management tools to release at one coordinated release time.

We initially felt the policy was reasonable too, but there are a
couple of specific recurring pain points:

1. Services land features which require installer/management tool
updates late in the cycle, or the work to update the configuration
tooling just doesn't happen fast enough during a given cycle.

2. Vendor integrations, similar to (1) but specific to enabling vendor
backends e.g for Neutron etc - the work to enable configuring specific
vendor plugins tends to lag the upstream releases (sometimes
significantly) because most vendors are focussed on consuming the
stable branch releases, not the development/master releases.

In an ideal world the answer would be for everyone working on these
integrations to land the installer (e.g puppet/TripleO/Kolla/...)
patches earlier, but even with the concessions around cycle-trailing
deadlines we're finding that there is ongoing pressure to backport
integrations which (according to stable-maint policy) are strictly
"features" but are actually more integration or enablement of features
which do exist in the version of OpenStack we're deploying.

Several releases ago (before we adopted stable: follows-policy) we
tried to solve this by allowing selected feature backports, but this
was insufficiently well defined (and thus abused) so we need some way
to enable vendor integrations and exposure of new features in the
underlying services, without allowing a backport-everything floodgate
to open ;)

I think one difference between TripleO/Puppet and Kolla here is AFAIK
Kolla has several ways to customize the configuration of deployed
services in a fairly unconstrained way, whereas the openstack puppet
modules and TripleO publish interfaces via a somewhat more static
module and "service plugin" model, which improves discoverability of
features e.g for the TripleO UI but causes a headache when you
discover support for a new vendor Neutron plugin is required well
after the upstream release deadline has passed.

Hope that helps clarify somewhat?

Steve

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

Re: [openstack-dev] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers

[Alex Schultz]

On Mon, Oct 16, 2017 at 7:33 AM, Steven Dake (stdake)  wrote:
> Emilien,
>
> I generally thought the stable policy seemed reasonable enough for lifecycle 
> management tools.  I’m not sure what specific problems you had in TripleO 
> although I did read your review.  Kolla was just tagged with the stable 
> policy, and TMK, we haven’t run into trouble yet, although the Kolla project 
> is stable and has been following the stable policy for about 18 months.  If 
> the requirements are watered down, the tag could potentially be meaningless.  
> We haven’t experienced this specific tag enough to know if it needs some 
> refinement for the specific use case of lifecycle management tools.  That 
> said, the follows release policy was created to handle the special case of 
> lifecycle management tool’s upstream sources not being ready for lifecycle 
> management tools to release at one coordinated release time.
>
> Kollians?  Any problems thus far with the stable policy?
>
> Cheers
> -steve
>

I'm not a Kolla person, but from the Puppet OpenStack stand point we
haven't been able to follow stable because we can't guarantee complete
configuration coverage for all the services. So while we don't
backport breaking changes (ie removing parameters from resources), we
do have to backport additions (adding params to resources/etc) as
folks start trying to use the upstream services. Since people are not
necessarily following master in their deployments, for example there's
a significant lag from operators who start trying to upgrade to Newton
about the time we're releasing Pike, etc etc.  These types of
additions could be seen as features because we didn't know we had to
add additional code to support the use case in the previous cycle.
Generally we're supporting our basic scenarios (which are pretty
extensive), but there are end user cases we don't test on a regular
basis which pop up from time to time where being able to say we
support a 'stable-policy' but will backport non-breaking changes if
necessary.

Thanks,
-Alex

>
> On 10/16/17, 4:27 AM, "Thierry Carrez"  wrote:
>
> Emilien Macchi wrote:
> > [...]
> > ## Proposal
> >
> > Proposal 1: create a new policy that fits for projects like installers.
> > I kicked-off something here: https://review.openstack.org/#/c/511968/
> > (open for feedback).
> > Content can be read here:
> > 
> http://docs-draft.openstack.org/68/511968/1/check/gate-project-team-guide-docs-ubuntu-xenial/1a5b40e//doc/build/html/stable-branches.html#support-phases
> > Tag created here: https://review.openstack.org/#/c/511969/ (same,
> > please review).
> >
> > The idea is really to not touch the current stable policy and create a
> > new one, more "relax" that suits well for projects like installers.
> >
> > Proposal 2: change the current policy and be more relax for projects
> > like installers.
> > I haven't worked on this proposal while it was something I was
> > considering doing first, because I realized it could bring confusion
> > in which projects actually follow the real stable policy and the ones
> > who have exceptions.
> > That's why I thought having a dedicated tag would help to separate them.
> >
> > Proposal 3: no change anywhere, projects like installer can't claim
> > stability etiquette (not my best option in my opinion).
> >
> > Anyway, feedback is welcome, I'm now listening. If you work on Kolla,
> > TripleO, OpenStack-Ansible, PuppetOpenStack (or any project who has
> > this need), please get involved in the review process.
>
> My preference goes to proposal 1, however rather than call it "relaxed"
> I would make it specific to deployment/lifecycle or cycle-trailing
> projects.
>
> Ideally this policy could get adopted by any such project. The
> discussion started on the review and it's going well, so let's see where
> it goes :)
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [nova] Interesting bug when unshelving an instance in an AZ and the AZ is gone

[Matt Riedemann]

This is interesting from the user point of view:

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

- The user creates an instance in a non-default AZ.
- They shelve offload the instance.
- The admin deletes the AZ that the instance was using, for whatever reason.
- The user unshelves the instance which goes back through scheduling and 
fails with NoValidHost because the AZ on the original request spec no 
longer exists.


Now the question is what, if anything, do we do about this bug? Some notes:

1. How reasonable is it for a user to expect in a stable production 
environment that AZs are going to be deleted from under them? We 
actually have a spec related to this but with AZ renames:


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

2. Should we null out the instance.availability_zone when it's shelved 
offloaded like we do for the instance.host and instance.node attributes? 
Similarly, we would not take into account the 
RequestSpec.availability_zone when scheduling during unshelve. I tend to 
prefer this option because once you unshelve offload an instance, it's 
no longer associated with a host and therefore no longer associated with 
an AZ. However, is it reasonable to assume that the user doesn't care 
that the instance, once unshelved, is no longer in the originally 
requested AZ? Probably not a safe assumption.


3. When a user unshelves, they can't propose a new AZ (and I don't think 
we want to add that capability to the unshelve API). So if the original 
AZ is gone, should we automatically remove the 
RequestSpec.availability_zone when scheduling? I tend to not like this 
as it's very implicit and the user could see the AZ on their instance 
change before and after unshelve and be confused.


4. We could simply do nothing about this specific bug and assert the 
behavior is correct. The user requested an instance in a specific AZ, 
shelved that instance and when they wanted to unshelve it, it's no 
longer available so it fails. The user would have to delete the instance 
and create a new instance from the shelve snapshot image in a new AZ. If 
we implemented Sylvain's spec in #1 above, maybe we don't have this 
problem going forward since you couldn't remove/delete an AZ when there 
are even shelved offloaded instances still tied to it.


Other options?

--

Thanks,

Matt

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

Re: [openstack-dev] [puppet] Proposing Alfredo Moralejo core on puppet-openstack-integration

[Emilien Macchi]

sounds good, updating Gerrit permissions now.


Thanks all,

On Fri, Oct 13, 2017 at 2:09 PM, Iury Gregory  wrote:
> +1
>
> On Oct 13, 2017 17:13, "Alex Schultz"  wrote:
>
> +1 thanks for the great contributions
>
> On Fri, Oct 13, 2017 at 11:49 AM, Mohammed Naser 
> wrote:
>>
>>
>> On Fri, Oct 13, 2017 at 1:21 PM, Emilien Macchi 
>> wrote:
>>>
>>> Alfredo has been doing an incredible work on maintaining Puppet
>>> OpenStack CI; by always testing OpenStack from trunk and taking care
>>> of issues. He has been involved in fixing the actual CI problems in
>>> OpenStack projects but also maintaining puppet-openstack-integration
>>> repository in a consistent and solid manner.
>>> Also, he has an excellent understanding how things work in this
>>> project and I would like to propose him part of p-o-i maintainers
>>> (among the rest of the whole core team and also dmsimard).
>>
>>
>> Indeed, Alfredo has helped us a lot by giving assistance from the
>> packagers
>> side of things and making sure that they release working packages, and
>> proposing fixes for issues that block promotion of packages to avoid
>> breaking our CI.
>>
>> +2 from me :)
>>
>>>
>>>
>>> As usual, feel free to vote and give feedback.
>>>
>>> Thanks,
>>> --
>>> Emilien Macchi
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing 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
>



-- 
Emilien Macchi

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

Re: [openstack-dev] [tripleo] Repo structure for ansible-k8s-roles-* under TripleO's umbrella

[Flavio Percoco]

On 11/10/17 07:48 +0200, Flavio Percoco wrote:

On 10/10/17 10:34 -0600, Alex Schultz wrote:

On Tue, Oct 10, 2017 at 5:24 AM, Flavio Percoco  wrote:

On 09/10/17 12:41 -0700, Emilien Macchi wrote:


On Mon, Oct 9, 2017 at 2:29 AM, Flavio Percoco  wrote:
[...]


1. A repo per role: Each role would have its own repo - this is the way
I've
been developing it on Github. This model is closer to the ansible way of
doing
things and it'll make it easier to bundle, ship, and collaborate on,
individual
roles. Going this way would produce something similar to what the
openstack-ansible folks have.



+1 on #1 for the composability.

[...]

Have we considered renaming it to something without tripleo in the name?
Or is it too specific to TripleO that we want it in the name?



The roles don't have tripleo in their names. The only role that mentions
tripleo
is tripleo specific. As for the APB, yeah, I had thought about renaming that
repo to something without tripleo in there: Perhaps just `ansible-k8s-apbs`.

I'm about to refactor this repo to remove all the code duplication. We
should be
able to generate most of the APB code that's in there from a python script.
We
could even have this script in tripleo_common, if it sounds sensible.



It should be it's own thing and not in tripleo_common.  When I was
proposing a cookiecutter repo it was because in Puppet we do the same
thing to bootstrap the modules[0].  It would be a good idea to
establish this upfront with the appropriate repo & zuul v3
configurations that could be used to test these modules. We have a
similar getting started with a new module doc[1] that we should
probably establish for these ansible-k8s-* roles.


Yes, I shall work on a cookiecutter repo for these roles. Good thinking.


I've moved ahead with this. I created a cookiecutter template and I've proceeded
to use this repo as the first one to migrate under `openstack/` for this work.

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

Please, provide feedback there. I'll soon create the governance patch.
Flavio



--
@flaper87
Flavio Percoco


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] [TripleO] Migrating TripleO jobs to native Zuul v3

[David Moreau Simard]

Hi,

Unless you've been hiding under a rock (which is totally
understandable), you know that Zuul v3 is here.

Zuul v3 can be seen as a hindrance as of late because it's been
messing up with the gate jobs or preventing your patches to merge,
etc.
Hopefully, the "legacy" Zuul v3 jobs are all fixed up now and things
are able to merge without too much troubles.
I'm here to tell you that Zuul v3 is in fact awesome and I'd like
TripleO to benefit from all it's glory ASAP.

I encourage everyone, not just people typically involved in CI, to
take a read at the Zuul v3 migration guide [1].
Zuul v3 opens a lot of opportunities to streamline, improve and
simplify the CI of TripleO in upstream.

I'd like to open up an informal "ask me anything" regarding what's
implied in properly migrating TripleO jobs to "native" Zuul v3 and
have set up an etherpad to start collecting questions [2].
We could do a recorded Bluejeans session sometime early next week.
I've set up a Doodle, please tell us what time would work best for you [3].

Paul Belanger and I will be there to answer questions from a Zuul v3
and upstream infrastructure perspective.

We might also have questions for you !
For example, how do we plan on keeping jobs "compatible" between
review.openstack.org and review.rdoproject.org ?

Thanks !

[1]: https://docs.openstack.org/infra/manual/zuulv3.html
[2]: https://etherpad.openstack.org/p/migrating-tripleo-zuulv3
[3]: https://doodle.com/poll/hfkcgrahwskm2ggv

David Moreau Simard
Senior Software Engineer | OpenStack RDO

dmsimard = [irc, github, twitter]

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

[openstack-dev] [nova] Notification update week 42

[Balazs Gibizer]

Hi,

Here is the status update / focus settings mail for w42.

Bugs

[High] https://bugs.launchpad.net/nova/+bug/1706563
TestRPC.test_cleanup_notifier_null fails with timeou
[High] https://bugs.launchpad.net/nova/+bug/1685333 Fatal Python error:
Cannot recover from stack overflow. - in py35 unit test job
The first bug is just a duplicate of the second. It seems the TetRPC
test suite has a way to end up in an infinite recusion.
Related patch https://review.openstack.org/#/c/507239/ has been merged. 
It makes the test run with timeout and lock support this might help 
with the troubleshooting of the bug. Based on logstash the last failure
happened at 12th of October and the above patch was merged 13th of 
October so it is even possible that the problem does not happen after 
the this related fix.


[High] https://bugs.launchpad.net/nova/+bug/1721843 Unversioned 
notifications not being sent
Regression in the legacy notifications introduced when the short 
cutting of the versioned notification payload generation was added. 
Only affects compute.instance.update legacy notification.

Fix merged on master backporting is in progress.


Versioned notification transformation
-
Here are the 3 patches for this week:
* https://review.openstack.org/#/c/443764 use context mgr in 
instance.delete
* https://review.openstack.org/#/c/410297 Transform missing delete 
notifications
* https://review.openstack.org/#/c/476459 Send soft_delete from context 
manager


Just a reminder that the versioned notification burndown chart is 
available on a new address: 
http://burndown.peermore.com/nova-notification/



Small improvements
--

* https://review.openstack.org/#/q/topic:refactor-notification-samples
Factor out duplicated notification sample data
This is a start of a longer patch series to deduplicate notification
sample data.
Takashi pointed out in the review that the current proposal actually 
changes the content of the sample appearing in our documentations. The 
reason is that some fields of the common sample fragment is overridden 
only during the functional test run and not during the doc generation. 
We agreed with Matt to try to make the override in a more clever way 
that applies to both the functional test and the doc generation.

The series needs to be updated.

Weekly meeting
--
Next subteam meeting will be held on 17th of October, Tuesday 17:00 UTC 
on openstack-meeting-4.

https://www.timeanddate.com/worldclock/fixedtime.html?iso=20171017T17


Cheers,
gibi




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

Re: [openstack-dev] [tc][election] Question for all candidates in TC election: What will you do if you don't win?

[Lance Bragstad]

On 10/16/2017 09:09 AM, Amrith Kumar wrote:
> In a recent conversation on #openstack-tc where we bemoaned the ills
> of Stackalytics and related management-by-objectives to Heisenberg's
> uncertainty principle, the conversation (on 10-03, for example) veered
> towards why people were interested in running for election to the
> Technical Committee.
>
> The observation was made that one motivation may be that an
> individual's employer derives some benefit from having a member on the
> technical committee. That would explain why some people (in the N-M,
> the ones who don't get elected) do not remain actively involved in the
> work of the TC if they are not elected. Some days later, I went and
> eyeballed the people who have run for TC elections over the past four
> cycles and then looked at what many of them did after the election, on
> the mailing list, and on the governance repository, and I think there
> is some truth to the observation.
>
> I've never been elected to the TC, I have run for election several
> times. Not winning the election has not in any way diminished my
> desire or drive to participate in the governance of OpenStack. Not
> winning has merely given me the (little more) luxury of not feeling so
> bad if I don't make it to the TC meeting (RIP), or not making it to as
> many of the office hours as I can. It has meant that I don't feel
> compelled to attend the TC meeting that precedes the Summit, and where
> possible I have made an effort to do so.
>
> In my mind winning or not winning merely changes one thing; do you get
> an actual vote that is counted towards a decision, on something that
> is put before the TC.
>
> Now, the question is this; does the vote really matter? I'm really
> happy with one thing that the TC has done over the years I've known of
> it; few (if any) decisions were actually made on a small margin of
> votes. Whether you have a vote, or not, participation has always been
> welcomed, and you get to say your piece. Never have I felt that not
> having a vote has made my opinion second class in any way.
>
>> If you are one of those (N-M) candidates, what then? What do you
>> believe you can do if you are not elected to the TC, and what will you
>> do? (concrete examples would be good)"
> I will still attend the office hours, I will still give dims grief and
> say that I preferred the regular TC meetings to office hours, I will
> still make time to get involved in more activities like the SWG and in
> the coming year if I have an opportunity to do that, I will. work to
> revive the SWG as a SIG. All of these are things (including giving
> dims a hard time) are things I've been doing already. I will continue
> to live by the decisions of the TC and I will continue to work to make
> OpenStack a better solution for me, a user of OpenStack.
>
>> "If you are one of the M elected candidates, the N-M candidates who
>> were not elected represent a resource?
> One thing that I have suggested in the past was the notion of
> alternates. For good reasons it was decided not to go this route but a
> similar benefit could in fact be achieved if the TC was able to tap
> these candidates to take on special projects, or drive specific
> initiatives. It is here that the issue of time came up; would people
> not elected be able to spare the time to do these kinds of things, and
> would their employers permit them the time to do it. I submit to you
> that while this is a reality, if in fact employers are not able to
> permit people the time to do these kinds of things if not elected, I
> submit to you that the motivations for running for election are flawed
> in the first place.
>
> Today, the responsibility to run too many of our "projects" are
> falling back on members of the TC, I'm thinking of Doug, Sean, Monty,
> ... I would try and leverage the N-M if at all possible to make for a
> stronger bench of leaders in the years to come.

Especially since we're starting to incorporate "champions" for the
community-wide goals we accept. I think championing a goal is a great
way to support the TC while improving one's own understanding of
OpenStack as a platform.

>
>
> -amrith
>
>
>
> On Sun, Oct 15, 2017 at 2:17 PM, Paul Belanger  wrote:
>> On Sun, Oct 15, 2017 at 08:15:51AM -0400, Amrith Kumar wrote:
>>> Full disclosure, I'm running for election as well. I intend to also
>>> provide an answer to the question I pose here, one that I've posed
>>> before on #openstack-tc in an office hours session.
>>>
>>> Question 1:
>>>
>>> "There are M open slots for the TC and there are N (>>M) candidates
>>> for those open slots. This is a good problem to have, no doubt.
>>> Choice, is a good thing, enthusiasm and participation are good things.
>>>
>>> But clearly, (N-M) candidates will not be elected.
>>>
>>> If you are one of those (N-M) candidates, what then? What do you
>>> believe you can do if you are not elected to the TC, and what will you
>>> do? (concrete examples would be good)"
>>>
>> ++
>>
>

Re: [openstack-dev] [tc][election] Question for candidates: How do you think we can make our community more inclusive?

[Doug Hellmann]

Excerpts from Colleen Murphy's message of 2017-10-15 11:38:47 +0200:
> On Fri, Oct 13, 2017 at 2:45 PM, Flavio Percoco  wrote:
> 
> > Greetings,
> >
> > Some of you, TC candidates, expressed concerns about diversity and
> > inclusiveness
> > (or inclusivity, depending on your taste) in your candidacy. I believe
> > this is a
> > broad, and some times ill-used, topic so, I'd like to know, from y'all,
> > how you
> > think we could make our community more inclusive. What areas would you
> > improve
> > first?
> >
> > Thank you,
> > Flavio
> >
> > --
> > @flaper87
> > Flavio Percoco
> >
> > First, we need more data. We need a better gender study that doesn't rely
> on first-name analysis and takes into account non-binary contributors. We
> need data on who is participating from which country (I'm reasonably sure
> this exists but I haven't found it published), what language they speak,
> whether they are participating in IRC meetings and why or why not (time
> zone problems? language barriers?). We need data on contribution by
> ethnicity.
> 
> A major problem in the tech world is not just attracting underrepresented
> contributors, but retaining them. They leave their communities or careers
> because of bias problems. To my knowledge, that doesn't happen in
> OpenStack, but just because I can't see it doesn't mean it's not there. A
> long-term study of participation by underrepresented demographics will help
> us answer this and fix it if necessary.
> 
> We do already know that we need to attract a more diverse contributor base.
> To do that, we need to expand and support outreach programs, especially
> things like Outreachy. It might not be a bad idea to start an
> OpenStack-specific Outreachy-type thing. We need to offer more mentors to
> the program so that we can support more interns.
> 
> We need to be friendlier to new people. You might have no idea how much a
> negative interaction on your first patch or your first question in IRC can
> frame your opinion of a community. A new person can't help but wonder if
> they are being treated that way because they have a feminine IRC nick or
> because their English wasn't good. I certainly think no one here tries to
> be unfriendly but I'm sure we could all do better to keep it in mind. I
> think Feilong's point about being publicly shamed for making a language and
> culture mistake is especially unfriendly and an example of something we can
> do better at.
> 
> Thanks for the great question.
> 
> Colleen

All good points, and well said.

Doug

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

Re: [openstack-dev] [tc][election] Question for all candidates in TC election: What will you do if you don't win?

[Doug Hellmann]

Excerpts from Amrith Kumar's message of 2017-10-15 08:15:51 -0400:
> Full disclosure, I'm running for election as well. I intend to also
> provide an answer to the question I pose here, one that I've posed
> before on #openstack-tc in an office hours session.
> 
> Question 1:
> 
> "There are M open slots for the TC and there are N (>>M) candidates
> for those open slots. This is a good problem to have, no doubt.
> Choice, is a good thing, enthusiasm and participation are good things.
> 
> But clearly, (N-M) candidates will not be elected.
> 
> If you are one of those (N-M) candidates, what then? What do you
> believe you can do if you are not elected to the TC, and what will you
> do? (concrete examples would be good)"
> 
> Question 2:
> 
> "If you are one of the M elected candidates, the N-M candidates who
> were not elected represent a resource?
> 
> Would you look to leverage/exploit that resource, and if so, how?
> (concrete examples would be good)"
> 
> -amrith
> 

If I'm not elected, I will still be working on all of the things I
mentioned in my nomination email (docs, encouraging participation from
folks who are <100% upstream, identifying new leaders and helping them
up their game, etc.) [1].

Regardless of the outcome of the election, I will be looking for
help with those things from everyone else who is running. We need a
leader for the proposed welcoming SIG [2], in particular.

Doug

[1] http://lists.openstack.org/pipermail/openstack-dev/2017-October/123059.html
[2] 
http://lists.openstack.org/pipermail/openstack-sigs/2017-September/84.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] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers

[Doug Hellmann]

Excerpts from Emilien Macchi's message of 2017-10-13 15:02:10 -0700:
> Greeting folks,
> 
> I hope we can get attention from stable-maint, release-managers and
> installers projects.
> 
> 
> ## Background
> 
> Some projects tried hard to follow stable policy but it didn't finish
> well: https://review.openstack.org/#/c/507924/
> This policy is too strict for projects like installers, although it's
> not a reason why the projects wouldn't be "stable".
> We decided to discuss again about the tag and how it works for installers.
> 
> ## Proposal
> 
> Proposal 1: create a new policy that fits for projects like installers.
> I kicked-off something here: https://review.openstack.org/#/c/511968/
> (open for feedback).
> Content can be read here:
> http://docs-draft.openstack.org/68/511968/1/check/gate-project-team-guide-docs-ubuntu-xenial/1a5b40e//doc/build/html/stable-branches.html#support-phases
> Tag created here: https://review.openstack.org/#/c/511969/ (same,
> please review).
> 
> The idea is really to not touch the current stable policy and create a
> new one, more "relax" that suits well for projects like installers.
> 
> Proposal 2: change the current policy and be more relax for projects
> like installers.
> I haven't worked on this proposal while it was something I was
> considering doing first, because I realized it could bring confusion
> in which projects actually follow the real stable policy and the ones
> who have exceptions.
> That's why I thought having a dedicated tag would help to separate them.
> 
> Proposal 3: no change anywhere, projects like installer can't claim
> stability etiquette (not my best option in my opinion).
> 
> Anyway, feedback is welcome, I'm now listening. If you work on Kolla,
> TripleO, OpenStack-Ansible, PuppetOpenStack (or any project who has
> this need), please get involved in the review process.
> 
> Thanks,

It seems appropriate for new versions of deployment tools to be
extended past the point where other types of projects allow feature
additions to add support for new hardware or operating systems to
old releases.

Option 1 seems like the most straightforward approach, because it
doesn't change the definition of the existing tag and cause confusion
about which definition applies to a given version of a given project.

Doug

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

Re: [openstack-dev] [tc][election] Question for all candidates in TC election: What will you do if you don't win?

[Amrith Kumar]

In a recent conversation on #openstack-tc where we bemoaned the ills
of Stackalytics and related management-by-objectives to Heisenberg's
uncertainty principle, the conversation (on 10-03, for example) veered
towards why people were interested in running for election to the
Technical Committee.

The observation was made that one motivation may be that an
individual's employer derives some benefit from having a member on the
technical committee. That would explain why some people (in the N-M,
the ones who don't get elected) do not remain actively involved in the
work of the TC if they are not elected. Some days later, I went and
eyeballed the people who have run for TC elections over the past four
cycles and then looked at what many of them did after the election, on
the mailing list, and on the governance repository, and I think there
is some truth to the observation.

I've never been elected to the TC, I have run for election several
times. Not winning the election has not in any way diminished my
desire or drive to participate in the governance of OpenStack. Not
winning has merely given me the (little more) luxury of not feeling so
bad if I don't make it to the TC meeting (RIP), or not making it to as
many of the office hours as I can. It has meant that I don't feel
compelled to attend the TC meeting that precedes the Summit, and where
possible I have made an effort to do so.

In my mind winning or not winning merely changes one thing; do you get
an actual vote that is counted towards a decision, on something that
is put before the TC.

Now, the question is this; does the vote really matter? I'm really
happy with one thing that the TC has done over the years I've known of
it; few (if any) decisions were actually made on a small margin of
votes. Whether you have a vote, or not, participation has always been
welcomed, and you get to say your piece. Never have I felt that not
having a vote has made my opinion second class in any way.

> If you are one of those (N-M) candidates, what then? What do you
> believe you can do if you are not elected to the TC, and what will you
> do? (concrete examples would be good)"

I will still attend the office hours, I will still give dims grief and
say that I preferred the regular TC meetings to office hours, I will
still make time to get involved in more activities like the SWG and in
the coming year if I have an opportunity to do that, I will. work to
revive the SWG as a SIG. All of these are things (including giving
dims a hard time) are things I've been doing already. I will continue
to live by the decisions of the TC and I will continue to work to make
OpenStack a better solution for me, a user of OpenStack.

> "If you are one of the M elected candidates, the N-M candidates who
> were not elected represent a resource?

One thing that I have suggested in the past was the notion of
alternates. For good reasons it was decided not to go this route but a
similar benefit could in fact be achieved if the TC was able to tap
these candidates to take on special projects, or drive specific
initiatives. It is here that the issue of time came up; would people
not elected be able to spare the time to do these kinds of things, and
would their employers permit them the time to do it. I submit to you
that while this is a reality, if in fact employers are not able to
permit people the time to do these kinds of things if not elected, I
submit to you that the motivations for running for election are flawed
in the first place.

Today, the responsibility to run too many of our "projects" are
falling back on members of the TC, I'm thinking of Doug, Sean, Monty,
... I would try and leverage the N-M if at all possible to make for a
stronger bench of leaders in the years to come.


-amrith



On Sun, Oct 15, 2017 at 2:17 PM, Paul Belanger  wrote:
> On Sun, Oct 15, 2017 at 08:15:51AM -0400, Amrith Kumar wrote:
>> Full disclosure, I'm running for election as well. I intend to also
>> provide an answer to the question I pose here, one that I've posed
>> before on #openstack-tc in an office hours session.
>>
>> Question 1:
>>
>> "There are M open slots for the TC and there are N (>>M) candidates
>> for those open slots. This is a good problem to have, no doubt.
>> Choice, is a good thing, enthusiasm and participation are good things.
>>
>> But clearly, (N-M) candidates will not be elected.
>>
>> If you are one of those (N-M) candidates, what then? What do you
>> believe you can do if you are not elected to the TC, and what will you
>> do? (concrete examples would be good)"
>>
> ++
>
> I'd like to see (N-M) candidates continue with TC by helping support M.
> Personally, I plan on participating more in TC office hours regardless of
> results. Or even reach out to TC and ask what non-TC members could do to help 
> TC
> more.
>
> Once thing I've noticed in the question period before elections was 'What more
> could the TC do'. I think it is also valid that we look at it the other way
> around as 'What

[openstack-dev] [oslo][blazar][heat] Remove oslotest.mockpatch

[ChangBo Guo]

The oslotest.mockpatch has been deprecated in favor of native fixtures in
[1] , need remove its usage in python-heatclient, python-blazarclient
[2][3],  Heat/Blazar team please help review, then we'll merge [4]


[1]https://review.openstack.org/#/c/245199/
[2]https://review.openstack.org/#/c/496120/
[3]https://review.openstack.org/#/c/496120/
[4] https://review.openstack.org/495534

-- 
ChangBo Guo(gcb)
Community Director @EasyStack
__
OpenStack Development Mailing 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] [policy] AWS IAM session

[Lance Bragstad]

Sending out a gentle reminder to vote for time slots that work for you
[0]. We'll keep the poll open for a few more days, or until we reach
quorum. Thanks!

[0] https://beta.doodle.com/poll/ntkpzgmcv3k6v5qu

On 10/11/2017 01:48 PM, Lance Bragstad wrote:
> Oh - one note about the doodle [0]. All proposed times are in UTC, so
> just keep that in mind when selecting your availability.
>
> Thanks!
>
> [0] https://beta.doodle.com/poll/ntkpzgmcv3k6v5qu
>
> On 10/11/2017 01:44 PM, Lance Bragstad wrote:
>> In today's policy meeting we went through and started prepping for
>> the session. Relevant information has been captured in the etherpad [0].
>>
>> We're going to hold the meeting using *Google* *Hangouts*. I'll
>> update the etherpad with a link to the hangout once we settle on a
>> date. If you plan on attending, please *vote* *for* *available*
>> *times* [1]. I've proposed a bunch of time slots (4 each day for the
>> next two weeks) to try and find a time that works for everyone.
>> People from US, AU, and EU will be trying to attended, so we're not
>> going to find a perfect time for everyone. Having said that, *we're
>> going to record the session*.
>>
>> Most of what we talked about in the meeting today uncovered the need
>> to go over the basics of AWS IAM. That should be something we can do
>> with a free account, which I'm going to sign up for. If we need more
>> time we can have another session or look at options for upgrading the
>> account.
>>
>>
>> [0] https://etherpad.openstack.org/p/analyzing-other-policy-systems
>> [1] https://doodle.com/poll/ntkpzgmcv3k6v5qu
>>
>> On 10/09/2017 04:23 PM, Lance Bragstad wrote:
>>> I've put a scheduling session on the books for the next policy
>>> meeting [0][1]. Advertising it here since folks who want to be
>>> involved have responded to the thread.
>>>
>>> Let's use this meeting time to iron out account details and figure
>>> out what exactly we want to get out of the session.
>>>
>>>
>>> [0] http://eavesdrop.openstack.org/#Keystone_Policy_Meeting
>>> [1] https://etherpad.openstack.org/p/keystone-policy-meeting
>>>
>>> On 10/05/2017 02:24 AM, Colleen Murphy wrote:
 On Tue, Oct 3, 2017 at 10:08 PM, Lance Bragstad
 mailto:lbrags...@gmail.com>> wrote:

 Hey all,

 It was mentioned in today's keystone meeting [0] that it would
 be useful
 to go through AWS IAM (or even GKE) as a group. With all the recent
 policy discussions and work, it seems useful to get our eyes on
 another
 system. The idea would be to spend time using a video
 conference/screen
 share to go through and play with policy together. The end
 result should
 keep us focused on the implementations we're working on today,
 but also
 provide clarity for the long-term vision of OpenStack's RBAC
 system.

 Are you interested in attending? If so, please respond to the
 thread.
 Once we have some interest, we can gauge when to hold the
 meeting, which
 tools we can use, and setting up a test IAM account.

 Thanks,

 Lance

 [0]
 
 http://eavesdrop.openstack.org/meetings/keystone/2017/keystone.2017-10-03-18.00.log.html#l-119
 
 

 Please count me in.

 Colleen


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



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

Re: [openstack-dev] [tripleo][networking] Organizing the networking squad

[Saravanan KR]

Thanks for initiating Brent. Yes, I would participate in the networking squad.

Regards,
Saravanan KR

On Mon, Oct 16, 2017 at 6:43 PM, Brent Eagles  wrote:
> Hi,
>
> On Tue, Oct 10, 2017 at 10:55 AM, Brent Eagles  wrote:
>>
>> Hi all,
>>
>> The list of TripleO squads includes a "networking squad". In previous
>> cycles, coordinating outside of IRC and email conversations seemed
>> unnecessary as there were only a few contributors and a small number of
>> initiatives. However, with future container related work, increased usage of
>> ansible, ongoing efforts like routed networks and NFV, os-net-config related
>> issues, and the increasing number of backends and networking related
>> services being added to TripleO, the world of TripleO networking seems
>> increasingly busy. I propose that we start organizing properly with periodic
>> sync-ups and coordinating efforts via etherpad (or similar) as well as
>> reporting into the weekly tripleo meeting.
>>
>> Cheers,
>>
>> Brent
>
>
> This was initially not directed at anyone in particular but I've added
> possible interested parties to this thread in case it gets lost in the
> noise! Please reply if you are interested in participating in the networking
> squad. Proposed first orders of business are:
>
>  - establish the squad's scope
>  - agree on whether we need a scheduled sync up meeting and if so, sort out
> a meeting time time
>  - outline initial areas of interest and concern and action items
>
> Cheers,
>
> Brent
>
>

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

Re: [openstack-dev] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers

[Steven Dake (stdake)]

Emilien,

I generally thought the stable policy seemed reasonable enough for lifecycle 
management tools.  I’m not sure what specific problems you had in TripleO 
although I did read your review.  Kolla was just tagged with the stable policy, 
and TMK, we haven’t run into trouble yet, although the Kolla project is stable 
and has been following the stable policy for about 18 months.  If the 
requirements are watered down, the tag could potentially be meaningless.  We 
haven’t experienced this specific tag enough to know if it needs some 
refinement for the specific use case of lifecycle management tools.  That said, 
the follows release policy was created to handle the special case of lifecycle 
management tool’s upstream sources not being ready for lifecycle management 
tools to release at one coordinated release time.

Kollians?  Any problems thus far with the stable policy?

Cheers
-steve


On 10/16/17, 4:27 AM, "Thierry Carrez"  wrote:

Emilien Macchi wrote:
> [...]
> ## Proposal
> 
> Proposal 1: create a new policy that fits for projects like installers.
> I kicked-off something here: https://review.openstack.org/#/c/511968/
> (open for feedback).
> Content can be read here:
> 
http://docs-draft.openstack.org/68/511968/1/check/gate-project-team-guide-docs-ubuntu-xenial/1a5b40e//doc/build/html/stable-branches.html#support-phases
> Tag created here: https://review.openstack.org/#/c/511969/ (same,
> please review).
> 
> The idea is really to not touch the current stable policy and create a
> new one, more "relax" that suits well for projects like installers.
> 
> Proposal 2: change the current policy and be more relax for projects
> like installers.
> I haven't worked on this proposal while it was something I was
> considering doing first, because I realized it could bring confusion
> in which projects actually follow the real stable policy and the ones
> who have exceptions.
> That's why I thought having a dedicated tag would help to separate them.
> 
> Proposal 3: no change anywhere, projects like installer can't claim
> stability etiquette (not my best option in my opinion).
> 
> Anyway, feedback is welcome, I'm now listening. If you work on Kolla,
> TripleO, OpenStack-Ansible, PuppetOpenStack (or any project who has
> this need), please get involved in the review process.

My preference goes to proposal 1, however rather than call it "relaxed"
I would make it specific to deployment/lifecycle or cycle-trailing
projects.

Ideally this policy could get adopted by any such project. The
discussion started on the review and it's going well, so let's see where
it goes :)

-- 
Thierry Carrez (ttx)

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


__
OpenStack Development Mailing 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][networking] Organizing the networking squad

[Brent Eagles]

​Hi,​

On Tue, Oct 10, 2017 at 10:55 AM, Brent Eagles  wrote:

> Hi all,
>
> The list of TripleO squads includes a "networking squad". In previous
> cycles, coordinating outside of IRC and email conversations seemed
> unnecessary as there were only a few contributors and a small number of
> initiatives. However, with future container related work, increased usage
> of ansible, ongoing efforts like routed networks and NFV, os-net-config
> related issues, and the increasing number of backends and networking
> related services being added to TripleO, the world of TripleO networking
> seems increasingly busy. I propose that we start organizing properly with
> periodic sync-ups and coordinating efforts via etherpad (or similar) as
> well as reporting into the weekly tripleo meeting.
>
> Cheers,
>
> Brent
>

This was initially not directed at anyone in particular but I've added
possible interested parties to this thread in case it gets lost in the
noise! Please reply if you are interested in participating in the
networking squad. Proposed first orders of business are:

 - establish the squad's scope
 - agree on whether we need a scheduled sync up meeting and if so, sort out
a meeting time time
 - outline initial areas of interest and concern and action items

Cheers,

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

Re: [openstack-dev] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers

[Jean-Philippe Evrard]

On 16 October 2017 at 12:27, Thierry Carrez  wrote:
> Emilien Macchi wrote:
>> [...]
>> ## Proposal
>>
>> Proposal 1: create a new policy that fits for projects like installers.
>> I kicked-off something here: https://review.openstack.org/#/c/511968/
>> (open for feedback).
>> Content can be read here:
>> http://docs-draft.openstack.org/68/511968/1/check/gate-project-team-guide-docs-ubuntu-xenial/1a5b40e//doc/build/html/stable-branches.html#support-phases
>> Tag created here: https://review.openstack.org/#/c/511969/ (same,
>> please review).
>>
>> The idea is really to not touch the current stable policy and create a
>> new one, more "relax" that suits well for projects like installers.
>>
>> Proposal 2: change the current policy and be more relax for projects
>> like installers.
>> I haven't worked on this proposal while it was something I was
>> considering doing first, because I realized it could bring confusion
>> in which projects actually follow the real stable policy and the ones
>> who have exceptions.
>> That's why I thought having a dedicated tag would help to separate them.
>>
>> Proposal 3: no change anywhere, projects like installer can't claim
>> stability etiquette (not my best option in my opinion).
>>
>> Anyway, feedback is welcome, I'm now listening. If you work on Kolla,
>> TripleO, OpenStack-Ansible, PuppetOpenStack (or any project who has
>> this need), please get involved in the review process.
>
> My preference goes to proposal 1, however rather than call it "relaxed"
> I would make it specific to deployment/lifecycle or cycle-trailing
> projects.
>
> Ideally this policy could get adopted by any such project. The
> discussion started on the review and it's going well, so let's see where
> it goes :)
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Thanks for the work there Emilien!

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

Re: [openstack-dev] [tc] Technical Committee Status update, October 13th

[Thierry Carrez]

Thierry Carrez wrote:
> == Final call on votes ==
> 
> We need to make a final call on the Glare project team application for
> the Queens cycle. If by the end of day (AOE) on Monday there is no
> majority support for it, the application will be denied. So please jump
> on that review if you haven't yet:
> 
> https://review.openstack.org/479285

I realize I wasn't clear here... This will be decided following the
charter rules[1], so with 5 votes in favor and 4 votes against (the
current status), this will be approved. In all cases I'll let the 3-day
grace period after we come to a decision here to let everyone else weigh in.

[1] https://governance.openstack.org/tc/reference/charter.html#motions

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers

[Thierry Carrez]

Emilien Macchi wrote:
> [...]
> ## Proposal
> 
> Proposal 1: create a new policy that fits for projects like installers.
> I kicked-off something here: https://review.openstack.org/#/c/511968/
> (open for feedback).
> Content can be read here:
> http://docs-draft.openstack.org/68/511968/1/check/gate-project-team-guide-docs-ubuntu-xenial/1a5b40e//doc/build/html/stable-branches.html#support-phases
> Tag created here: https://review.openstack.org/#/c/511969/ (same,
> please review).
> 
> The idea is really to not touch the current stable policy and create a
> new one, more "relax" that suits well for projects like installers.
> 
> Proposal 2: change the current policy and be more relax for projects
> like installers.
> I haven't worked on this proposal while it was something I was
> considering doing first, because I realized it could bring confusion
> in which projects actually follow the real stable policy and the ones
> who have exceptions.
> That's why I thought having a dedicated tag would help to separate them.
> 
> Proposal 3: no change anywhere, projects like installer can't claim
> stability etiquette (not my best option in my opinion).
> 
> Anyway, feedback is welcome, I'm now listening. If you work on Kolla,
> TripleO, OpenStack-Ansible, PuppetOpenStack (or any project who has
> this need), please get involved in the review process.

My preference goes to proposal 1, however rather than call it "relaxed"
I would make it specific to deployment/lifecycle or cycle-trailing
projects.

Ideally this policy could get adopted by any such project. The
discussion started on the review and it's going well, so let's see where
it goes :)

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [TripleO] containerized undercloud in Queens

[Bogdan Dobrelya]

On 10/3/17 10:46 PM, Dan Prince wrote:
> 
> 
> This reduces our complexity greatly I think in that once it is completed
> will allow us to eliminate two project (instack and instack-undercloud)
> and the maintenance thereof. Furthermore, as this dovetails nice with
> the Ansible
>  
> 
>  IMHO doit.sh is not acceptable as an undercloud installer and
> this is what I've been trying to point out as the actual impact to the
> end user who has to use this thing.
> 
> 
> doit.sh is an example of where the effort is today. It is essentially
> the same stuff we document online
> here: http://tripleo.org/install/containers_deployment/undercloud.html.
> 
> Similar to quickstart it is just something meant to help you setup a dev
> environment.

Please note that quickstart can "doit.sh" [0] as well and even more :)
Although the undercloud_deploy role needs to be supported in the
quickstart.sh maybe, and its documentation [1] should be explaining the
case better.

Undercloud_install_script and the script template itself fully addresses
the needed flexibility for developers and operators. You can git clone /
pip install things, or do not.

It follows the standard quickstart way, which is jinja-templating bash
scripts in order to provide an operator-ish friendly, and independent
from Ansible et al, way to reproduce the scripted steps. And helps to
auto-generate documentation as well.

[0]
https://git.openstack.org/cgit/openstack/tripleo-quickstart-extras/tree/roles/undercloud-deploy/README.md
[1] https://docs.openstack.org/tripleo-quickstart/latest/


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando

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

Re: [openstack-dev] [tc][election] Question for candidates: How do you think we can make our community more inclusive?

[Flavio Percoco]

/me waves

Thanks a bunch for replying to my email. As some of you may know, this is a
topic that is very close to me and I that I pay lots of attention to. There's
some overlap in some of your replies and I've taken notes offline so we can work
together on some of them (although I'd love to see y'all pushing your ideas
forward).

I've decided to not summarize the thread here because I would prefer to
encourage voters to read each of the replies. A summary from me would not pay
justice to the effort you've put replying to my question.

Thanks again and good luck to y'all,
Flavio

On 13/10/17 14:45 +0200, Flavio Percoco wrote:

Greetings,

Some of you, TC candidates, expressed concerns about diversity and inclusiveness
(or inclusivity, depending on your taste) in your candidacy. I believe this is a
broad, and some times ill-used, topic so, I'd like to know, from y'all, how you
think we could make our community more inclusive. What areas would you improve
first?

Thank you,
Flavio

--
@flaper87
Flavio Percoco




--
@flaper87
Flavio Percoco


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] [tc][election] Question for candidates: How do you think we can make our community more inclusive?

[Flavio Percoco]

On 15/10/17 01:26 +0100, Erno Kuvaja wrote:

What we really need to focus on is to get people _wanting_ to join us.
There is next to nothing easy in OpenStack with all it's complexity
and that's perfectly fine. Easy is not fun, we all want to challenge
ourselves. And we have amazing community to support those who wants to
join and make the difference. That is the group we need to grow and
when we run out of scalability of helping the people who really wants
to make the effort, then we should focus streamlining that process.

I'm eager to say, we're wasting our time trying to make it super
welcoming and easy just to join for everyone as long as we do not have
the queue of people who really wants to make a difference. Think about
it, feel free to tell that I'm totally wrong and just being ass by
saying this, and when you do, please explain why you think so.


I don't think you're totally wrong and I also think we might be having a problem
attracting people to the community. Nevertheless, I don't think attracting
people to the community is entirely related to being inclusive. If you do a
massive marketing campain to attract people and your community is not welcoming
(or simply ready to deal with that) then you'll end up pushing them away, hence
my question ;)

As you correctly pointed out, our community is amaizing but not perfect. We do
have some serious issues to deal with to be more inclusive. So, I think you're
onto something and your answer is valid, perhaps better in a different context.

Flavio

--
@flaper87
Flavio Percoco


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] [nova][ironic] Concerns over rigid resource class-only ironic scheduling

[Nisha Agarwal]

Hi Matt,

As i understand John's spec https://review.openstack.org/#/c/507052/, it is
actually a replacement for capabilities(qualitative only) for ironic. It
doesnt cover the quantitative capabilities as 'traits' are meant only for
qualitative capabilities. Quantitative capabilities are covered by resource
classes in Nova. We have few (one or two) quantitative capabilities already
supported in ironic.

Regards
Nisha

On Thu, Oct 5, 2017 at 9:09 PM, Matt Riedemann  wrote:

> On 9/7/2017 2:48 PM, Nisha Agarwal wrote:
>
>> Hi Ironic Operators,
>>
>>  From Pike, ironic nodes get scheduled based on just the resource class
>> from nova. Do you guys see any concerns over this "rigid resource class
>> only ironic scheduling"?
>>
>> To be more specific, at your datacentre/production environment what all
>> filters are configured in nova.conf (configuration file for nova) for
>> scheduling an ironic node? Do you use RamFilter/DiskFilter/CoreFilter in
>> the "use_baremetal_filters" for ironic nodes scheduling from nova?
>>
>> Thanks and Regards
>> Nisha
>>
>>
>>
>> 
>> __
>> 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
>>
>>
> Bringing this back up.
>
> Does this nova spec from John Garbutt help you?
>
> https://review.openstack.org/#/c/507052/
>
> --
>
> Thanks,
>
> Matt
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
The Secret Of Success is learning how to use pain and pleasure, instead
of having pain and pleasure use you. If You do that you are in control
of your life. If you don't life controls you.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] Kernel parameters needed to boot from iscsi

[Yolanda Robla Mota]

Hi
Recently i've been helping some customers in the boot from ISCSI feature.
So far everything was working, but we had a problem when booting the
deployment image.
It needed specifically a flag rd.iscsi.ibft=1 rd.iscsi.firmware=1 in the
grub commands. But as the generated deployment image doesn't contain these
flags, ISCSI was not booting properly. For other hardware setups, different
flags may be needed.
The solution was to manually execute a virt-customize on the deployment
image to hardcode these parameters.
I wonder if we can add some feature in Ironic to support it. We have
discussed about kernel parameters several times. But at this time, it
affects ISCSI booting. Not having a way in Ironic to customize these
parameters forces to manual workarounds.
So can we reconsider the proposal to add kernel parameters there? It could
be a settable argument (driver_info/kernel_args), and then the IPA could
set the parameters properly on the image. Or any other option is welcome.
What are your thoughts there?

Thanks

-- 

Yolanda Robla Mota

Principal Software Engineer, RHCE

Red Hat



C/Avellana 213

Urb Portugal

yrobl...@redhat.comM: +34605641639


__
OpenStack Development Mailing 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] How is the interface for tftpboot server typically configured on OVS ?

[Mark Goddard]

Here's an ASCII diagram[1] of the network topology on the controllers of a
system we deployed earlier this year using kayobe[2].

As Sam said, we don't touch the neutron OVS bridge, in this case because
it's managed entirely by kolla-ansible. Instead, we create a Linux bridge
which is plugged into a trunk port (eno1), and add a VLAN subinterface to
the bridge to access the provisioning VLAN. The TFTP server listens on this
interface (breno1.7). The tagged VLAN traffic is passed through to the
neutron OVS bridge via a veth pair. This saves us an ethernet interface at
the expense of virtual complexity.

Mark

[1] http://paste.openstack.org/show/623681/
[2] https://kayobe.readthedocs.io

On 13 October 2017 at 10:55, Sam Betts (sambetts) 
wrote:

> There are multiple options for doing this, but I suggest avoiding manually
> plumbing anything into OVS as it can lead to some nastiness in the future.
>
>
>
> My personal recommended way to do this is to create the provisioning
> network in neutron with a known VLAN and trunk it separately down to the
> ironic services.
>
>
>
> To do this first exclude the chosen VLAN from the range of tenant
> provisionable VLANs, and then create the provisioning network in neutron
> with the --physical-network  and --segmentation-id  flags.
>
>
>
> Next you need to create the subnet for that network, and we know that we
> need to run the ironic services (like TFTP on this network) so when you
> create the subnet you need to exclude some IP addresses from the allocation
> pool (these IP address will be statically assigned by us outside of
> neutron’s control) for example subnet CIDR 10.0.0.0/24, allocation-pool:
> 10.0.0.1, 10.0.0.250 will give us 4 IPs for ironic services.
>
>
>
> Then on my Ironic services server I trunk the provisioning VLAN down on an
> interface that isn’t assigned to a bridge/given to neutron (normally I use
> the same network interface which is used for inter-service communication
> e.g. eth0 when eth1 is assigned to neutron) and then create a VLAN
> sub-interface on that NIC e.g. eth0. and assign it one
> of the IP addresses I reserved from the allocation pool earlier.
>
>
>
> The Ironic TFTP server, the Ironic API, and conductor for provisioning
> then operate over this IP address/network interface.
>
>
>
> Then when I need to scale up our Ironic services, I can replicate the same
> trunk and sub-interface on each conductor server assigning a different one
> of the reserved IPs to each, letting our ironic services happily scale up
> horizontally as intended.
>
>
>
> Sam
>
>
>
> On 12/10/2017, 23:42, "Waines, Greg"  wrote:
>
>
>
> Hey,
>
>
>
> We are in the process of integrating OpenStack Ironic into our own
> OpenStack Distribution.
>
>
>
> One of the areas that we cannot find a good description of is:
>
> How is the interface for the tftpboot server typically configured on
> OVS ?
>
>
>
> i.e.
>
> · i know tftpboot server runs on the same node as
> ironic-conductor,
>
> · i know tftpboot server needs to have an interface on the
> ‘provisioning’ tenant network, and
>
> · i know the tftpboot server IP address and the ‘provisioning’
> network are configured in ironic.conf
>
> · BUT
>
> o   how is the interface on the ‘provisioning’ tenant network configured
> for tftpboot server ?
>
> §  i.e. how is it configured on OVS ?
>
> · assuming it would be an OVS virtual port that would be
> connected to
> the ‘provisioning’ tenant network
>
> §  i.e. how is this done upstream ?
> e.g.
>
> · is a TAP(?) interface configured ?
> and
>
> · is a Neutron Port configured on the ‘provisioning’ tenant
> network,
> with a reserved IP Address from ‘provisioining’ tenant network’s subnet and
>  a MAC address from TAP interface ?
> and
>
> · the L2-Agent manages the binding of the TAP Interface to the
> ‘provisioning’ tenant network within OVS ?
>
>
>
> Can anybody point me to or provide a detailed description of how this is
> done upstream ?
>
>
>
> thanks in advance,
>
> Greg.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] IBM z/VM CI asks for reporting permission to Nova changes

[Chen CH Ji]

Thanks for your help, we have been running the CI for months and star to
report to nova patches after grant the access
could you please help to approve https://review.openstack.org/#/c/464915/
as we already got a +2 and
please let us know anything we need to get the spec approved, thanks~


Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82451493
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Matt Riedemann 
To: openstack-dev@lists.openstack.org
Date:   10/13/2017 09:57 PM
Subject:Re: [openstack-dev] [nova] IBM z/VM CI asks for reporting
permission to Nova changes



On 10/11/2017 11:42 PM, Xiao Mei GZ Zheng wrote:
> Hello,
>
> I'm requesting reporting permission (non-voting) to Nova changes for the
> IBM z/VM CI. The wiki is on link [1].
>
> We designed the CI using nodepool , zuul and Jenkins. The newly uploaded
> patches will receive an initial +/-1 reports from Jenkins only for the
> nova project (just comments on patches but not vote on them). Tests
> completed on the z/VM Driver CI system check-nova pipeline. For more
> information see[2]. To recheck it, you just submit a comment with only
> zvm:recheck in the comment.
>
> The IBM z/VM CI system has been running for a long time in a stable
> fashion. We present all test artifacts on a public link [3] to make
> debugging failed tests easier. You can see environment details,
> openstack logs and tempest logs.
>
> * Gerrit Account: zvmosci
>
> * Gerrit query on patches where the CI commented: [4]
>
> * Proposal for naming: IBM z/VM CI
>
> For any questions feel free to reach out to me (Laurene) or to Leon!
>
> [1]
https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.openstack.org_wiki_ThirdPartySystems_IBM-5Fz_VM-5FCI&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0&m=PMHHg_hTd5A4J7k5WJv0Sxq-IwWnMCSWpu2_il1dv8E&s=TW3Umekz89KQIa8RANGVjAIS5wwCD0jlTAUCVlPAWOU&e=

>
> [2]
https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.openstack.org_wiki_ZVMDriver_zVM-2DCI&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0&m=PMHHg_hTd5A4J7k5WJv0Sxq-IwWnMCSWpu2_il1dv8E&s=zPstbECoa_-scgebDBtaWIyGOUtli7hU1RmV6T394pQ&e=

>
>
> [3] http://extbasicopstackcilog01.podc.sl.edst.ibm.com/ci_status/
>
>
> [4]
https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_410596_&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0&m=PMHHg_hTd5A4J7k5WJv0Sxq-IwWnMCSWpu2_il1dv8E&s=CjmX4DjgHSnrRJaJQiJj3EKgXACa8f1MxE84mMhJ7Kw&e=

>
> Thanks & Best Regards!
>
> Laurene(Xiao Mei) Zheng
> 
> Software developer, CSTL
> IBM China Systems & Technology Lab (CSTL)
>
>
>
>
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0&m=PMHHg_hTd5A4J7k5WJv0Sxq-IwWnMCSWpu2_il1dv8E&s=6cUIH7XMNFR3ov4O7-TvCpka88FwFBFdHOSuVFOK4lY&e=

>

This is OK for me. The latest CI run I see is here:

http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-7096/


It looks like the CI used to take about 3.5 hours from [4] but now it's
taking a little over an hour, so that's good.

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0&m=PMHHg_hTd5A4J7k5WJv0Sxq-IwWnMCSWpu2_il1dv8E&s=6cUIH7XMNFR3ov4O7-TvCpka88FwFBFdHOSuVFOK4lY&e=




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