Re: [openstack-dev] [all] log-classify project update (anomaly detection in CI/CD logs)

[Tristan Cacqueray]

On July 5, 2018 9:17 am, Tristan Cacqueray wrote:

On July 3, 2018 7:39 am, Tristan Cacqueray wrote:
[...] 

There is a lot to do and it will be challening. To that effect, I would
like to propose an initial meeting with all interested parties.
Please register your irc name and timezone in this etherpad:

  https://etherpad.openstack.org/p/log-classify


So far, the mean timezone is UTC+1.75, I've added date proposal from the
16th to the 20th of July. Please adds a '+' to the one you can attend.
I'll follow-up next week with an ical file for the most popular.



Wednesday 18 July at 12:00 UTC has the most votes.
There is now a #log-classify channel on Freenode.
And I also started an infra-spec draft here:
https://review.openstack.org/#/c/581214/1/specs/log_classify.rst

See you then.
-Tristan
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//yaml2ical agendas//EN
BEGIN:VEVENT
SUMMARY:log-classify
DTSTART;VALUE=DATE-TIME:20180718T12Z
DURATION:PT1H
DESCRIPTION:Project:  log-classify\nChair:  tristanC\nDescription:  Kickst
 art log-classify
LOCATION:#log-classify
END:VEVENT
END:VCALENDAR


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

[openstack-dev] [requirements][infra] Maintaining constraints for several python versions

[Tony Breeds]

Hi Folks,
We have a pit of a problem in openstack/requirements and I'd liek to
chat about it.

Currently when we generate constraints we create a venv for each
(system) python supplied on the command line, install all of
global-requirements into that venv and capture the pip freeze.

Where this falls down is if we want to generate a freeze for python 3.4
and 3.5 we need an image that has both of those.  We cheated and just
'clone' them so if python3 is 3.4 we copy the results to 3.5 and vice
versa.  This kinda worked for a while but it has drawbacks.

I can see a few of options:

1. Build pythons from source and use that to construct the venv
   [please no]

2. Generate the constraints in an F28 image.  My F28 has ample python
   versions:
 - /usr/bin/python2.6
 - /usr/bin/python2.7
 - /usr/bin/python3.3
 - /usr/bin/python3.4
 - /usr/bin/python3.5
 - /usr/bin/python3.6
 - /usr/bin/python3.7
   I don't know how valid this still is but in the past fedora images
   have been seen as unstable and hard to keep current.  If that isn't
   still the feeling then we could go down this path.  Currently there a
   few minor problems with bindep.txt on fedora and generate-constraints
   doesn't work with py3 but these are pretty minor really.

3. Use docker images for python and generate the constraints with
   them.  I've hacked up something we could use as a base for that in:
  https://review.openstack.org/581948

   There are lots of open questions:
 - How do we make this nodepool/cloud provider friendly ?
   * Currently the containers just talk to the main debian mirrors.
 Do we have debian packages? If so we could just do sed magic.
 - Do/Can we run a registry per provider?
 - Can we generate and caches these images and only run pip install -U
   g-r to speed up the build
 - Are we okay with using docker this way?

I like #2 the most but I wanted to seek wider feedback.



Yours Tony.


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

[openstack-dev] [publiccloud-wg] [adjutant] Input on Adjutant's official project status

[Adrian Turjak]

Hello fellow public cloud providers (and others)!

Adjutant is in the process of being voted in (or not) as an official
project as part of OpenStack, but to help over the last few hurdles,
some input from the people who would likely benefit the most directly
from such a service existing would really be useful.

In the past you've probably talked to me about the need for some form of
business logic related APIs and services in OpenStack (signup, account
termination, project/user management, billing details management, etc).
In that space I've been trying to push Adjutant as a solution, not
because it's the perfect solution, but because we are trying to keep the
service as a cloud agnostic solution that could be tweaked for the
unique requirements of various clouds. It's also a place were we can
collaborate on these often rather miscellaneous business logic
requirements rather than us each writing our own entirely distinct thing
and wasting time and effort reinventing the wheel again and again.

The review in question where this discussion has been happening for a while:
https://review.openstack.org/#/c/553643/

And if you don't know much about Adjutant, here is a little background.

The current mission statement is:
"To provide an extensible API framework for exposing to users an
organization's automated business processes relating to account
management across OpenStack and external systems, that can be adapted to
the unique requirements of an organization's processes."

The docs: https://adjutant.readthedocs.io/en/latest/
The code: https://github.com/openstack/adjutant

And here is a rough feature list that was put together as part of the
review process for official project status:
https://etherpad.openstack.org/p/Adjutant_Features

If you have any questions about the service, don't hesitate to get in
touch, but some input on the current discussion would be very welcome!

Cheers,
Adrian Turjak





pEpkey.asc
Description: application/pgp-keys
__
OpenStack Development Mailing 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]API update week 5-11

[Zhenyu Zheng]

>
> 2. Abort live migration in queued state:
> -
> https://blueprints.launchpad.net/nova/+spec/abort-live-migration-in-queued-status
>
> -
> https://review.openstack.org/#/q/topic:bp/abort-live-migration-in-queued-status+(status:open+OR+status:merged)
>
> - Weekly Progress: Review is going and it is in nova runway this week. In
> API office hour, we discussed about doing the compute service version
> checks on compute.api.py side than on rpc side. Dan has point of doing it
> on rpc side where migration status can changed to running. We decided to
> further discussed it on patch.


This is my own defence, Dan's point seems to be that the actual rpc version
pin could be set to be lower than the can_send_version even when the
service version is new enough, so he thinks doing it in rpc is better.

On Thu, Jul 12, 2018 at 9:15 AM Ghanshyam Mann 
wrote:

> Hi All,
>
> Please find the Nova API highlights of this week.
>
> Weekly Office Hour:
> ===
> We had more attendees in this week office hours.
>
> What we discussed this week:
> - Discussion on API related BP. Discussion points are embedded inline with
> BP weekly progress in next section.
> - Triage 1 new bug and Alex reviewed one in-progress
>
> Planned Features :
> ==
> Below are the API related features for Rocky cycle. Nova API Sub team will
> start reviewing those to give their regular feedback. If anythings missing
> there feel free to add those in etherpad-
> https://etherpad.openstack.org/p/rocky-nova-priorities-tracking
>
> 1. Servers Ips non-unique network names :
> -
> https://blueprints.launchpad.net/nova/+spec/servers-ips-non-unique-network-names
> - Spec Merged
> -
> https://review.openstack.org/#/q/topic:bp/servers-ips-non-unique-network-names+(status:open+OR+status:merged)
> - Weekly Progress: Spec is merged. I am in contact with author about code
> update (sent email last night). If no response till this week, i will push
> the code update for this BP.
>
> 2. Abort live migration in queued state:
> -
> https://blueprints.launchpad.net/nova/+spec/abort-live-migration-in-queued-status
> -
> https://review.openstack.org/#/q/topic:bp/abort-live-migration-in-queued-status+(status:open+OR+status:merged)
> - Weekly Progress: Review is going and it is in nova runway this week. In
> API office hour, we discussed about doing the compute service version
> checks on compute.api.py side than on rpc side. Dan has point of doing it
> on rpc side where migration status can changed to running. We decided to
> further discussed it on patch.
>
> 3. Complex anti-affinity policies:
> -
> https://blueprints.launchpad.net/nova/+spec/complex-anti-affinity-policies
> -
> https://review.openstack.org/#/q/topic:bp/complex-anti-affinity-policies+(status:open+OR+status:merged)
> - Weekly Progress: Good review progress. In API office hour, we discussed
> on 2 points-
>1. whether request also need to have flat format like response. IMO
> we need to have flat in both request and response. Yikun need more opinion
> on that.
>
>2. naming fields to policy_* as we are moving these new fields in
> flat format. I like to have policy_* for clear understanding of attributes
> by their name. This is not concluded
>  and alex will give feedback on patch.
>Discussion is on patch for consensus on naming things.
>
> 4. Volume multiattach enhancements:
> -
> https://blueprints.launchpad.net/nova/+spec/volume-multiattach-enhancements
> -
> https://review.openstack.org/#/q/topic:bp/volume-multiattach-enhancements+(status:open+OR+status:merged)
> - Weekly Progress: mriedem mentioned in last week status mail that he will
> continue work on this.
>
> 5. API Extensions merge work
> - https://blueprints.launchpad.net/nova/+spec/api-extensions-merge-rocky
> -
> https://review.openstack.org/#/q/project:openstack/nova+branch:master+topic:bp/api-extensions-merge-rocky
> - Weekly Progress: I did not get chance to push more patches on this. I
> will target this one before next office hour.
>
> 6. Handling a down cell
>  - https://blueprints.launchpad.net/nova/+spec/handling-down-cell
>  -  Spec mriedem  mentioned in previous week ML is merged -
> https://review.openstack.org/#/c/557369/
>
> Bugs:
> 
> Triage 1 new bug and Alex reviewed one in-progress. I did not do my home
> work of doing review on in-progress patches (i will accommodate that in
> next week)
>
> This week Bug Progress:
> Critical: 0->0
> High importance: 2->3
> By Status:
> New:  1->0
> Confirmed/Triage: 30-> 31
> In-progress: 36->36
> Incomplete: 4->4
> =
> Total: 70->71
>
> NOTE- There might be some bug which are not tagged as 'api' or 'api-ref',
> those are not in above list. Tag such bugs so that we can keep our eyes.
>
> Ref: https://etherpad.openstack.org/p/nova-api-weekly-bug-report
>
> -gmann
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage 

[openstack-dev] [qa][ptg] Stein PTG Planning for QA

[Ghanshyam Mann]

Hi All,

As we are close to Stein PTG Denver, I have prepared the etherpad[1] to collect 
the PTG topic ideas for QA. Please start adding your item/topic you want to 
discuss in PTG or comment on proposed topics.  Even you are not making to PTG 
physically, still add your topic which you want us to discuss or progress on.  

[1] https://etherpad.openstack.org/p/qa-stein-ptg

-gmann





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

[openstack-dev] [nova]API update week 5-11

[Ghanshyam Mann]

Hi All, 

Please find the Nova API highlights of this week. 

Weekly Office Hour: 
=== 
We had more attendees in this week office hours.  

What we discussed this week: 
- Discussion on API related BP. Discussion points are embedded inline with BP 
weekly progress in next section. 
- Triage 1 new bug and Alex reviewed one in-progress 

Planned Features : 
== 
Below are the API related features for Rocky cycle. Nova API Sub team will 
start reviewing those to give their regular feedback. If anythings missing 
there feel free to add those in etherpad- 
https://etherpad.openstack.org/p/rocky-nova-priorities-tracking 

1. Servers Ips non-unique network names : 
- 
https://blueprints.launchpad.net/nova/+spec/servers-ips-non-unique-network-names
 
- Spec Merged
- 
https://review.openstack.org/#/q/topic:bp/servers-ips-non-unique-network-names+(status:open+OR+status:merged)
 
- Weekly Progress: Spec is merged. I am in contact with author about code 
update (sent email last night). If no response till this week, i will push the 
code update for this BP.  

2. Abort live migration in queued state: 
- 
https://blueprints.launchpad.net/nova/+spec/abort-live-migration-in-queued-status
 
- 
https://review.openstack.org/#/q/topic:bp/abort-live-migration-in-queued-status+(status:open+OR+status:merged)
 
- Weekly Progress: Review is going and it is in nova runway this week. In API 
office hour, we discussed about doing the compute service version checks on 
compute.api.py side than on rpc side. Dan has point of doing it on rpc side 
where migration status can changed to running. We decided to further discussed 
it on patch. 

3. Complex anti-affinity policies: 
- https://blueprints.launchpad.net/nova/+spec/complex-anti-affinity-policies 
- 
https://review.openstack.org/#/q/topic:bp/complex-anti-affinity-policies+(status:open+OR+status:merged)
 
- Weekly Progress: Good review progress. In API office hour, we discussed on 2 
points-
   1. whether request also need to have flat format like response. IMO we 
need to have flat in both request and response. Yikun need more opinion on 
that. 

   2. naming fields to policy_* as we are moving these new fields in flat 
format. I like to have policy_* for clear understanding of attributes by their 
name. This is not concluded 
 and alex will give feedback on patch.
   Discussion is on patch for consensus on naming things. 

4. Volume multiattach enhancements: 
- https://blueprints.launchpad.net/nova/+spec/volume-multiattach-enhancements 
- 
https://review.openstack.org/#/q/topic:bp/volume-multiattach-enhancements+(status:open+OR+status:merged)
 
- Weekly Progress: mriedem mentioned in last week status mail that he will 
continue work on this. 

5. API Extensions merge work 
- https://blueprints.launchpad.net/nova/+spec/api-extensions-merge-rocky 
- 
https://review.openstack.org/#/q/project:openstack/nova+branch:master+topic:bp/api-extensions-merge-rocky
 
- Weekly Progress: I did not get chance to push more patches on this. I will 
target this one before next office hour. 

6. Handling a down cell
 - https://blueprints.launchpad.net/nova/+spec/handling-down-cell
 -  Spec mriedem  mentioned in previous week ML is merged - 
https://review.openstack.org/#/c/557369/

Bugs: 
 
Triage 1 new bug and Alex reviewed one in-progress. I did not do my home work 
of doing review on in-progress patches (i will accommodate that in next week) 

This week Bug Progress: 
Critical: 0->0 
High importance: 2->3 
By Status:
New:  1->0
Confirmed/Triage: 30-> 31
In-progress: 36->36
Incomplete: 4->4
=
Total: 70->71

NOTE- There might be some bug which are not tagged as 'api' or 'api-ref', those 
are not in above list. Tag such bugs so that we can keep our eyes. 

Ref: https://etherpad.openstack.org/p/nova-api-weekly-bug-report 

-gmann 





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

[openstack-dev] [tripleo][ci] PTG Stein topics

[Wesley Hayutin]

Greetings,

Starting to collect thoughts and comments here,
https://etherpad.openstack.org/p/tripleoci-ptg-stein

Thanks
-- 

Wes Hayutin

Associate MANAGER

Red Hat



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


View my calendar and check my availability for meetings HERE

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

[openstack-dev] [keystone] Federation testing

[Ildiko Vancsa]

Hi,

Within the Edge Computing Group we have a few people interested in Keystone 
federation testing starting with general federation and moving to edge specific 
test cases onwards.

In case you are interested in this activity, we are organizing a call for next 
Thursday to talk about basic testing in OpenStack including identifying tasks 
and volunteers to complete them. We would like to use the time to clarify 
questions about Keystone federation capabilities if there’s any.

We are also collaborating with the OPNFV Edge Cloud project for advanced test 
scenarios which we will also discuss on the call.

The call details are here: 
https://wiki.openstack.org/wiki/Edge_Computing_Group#Federation_Testing_Call

Please check out the materials on this etherpad prior to the call if you plan 
to join: https://etherpad.openstack.org/p/ECG_Keystone_Testing

Please let me know if you have any questions.

Thanks and Best Regards,
Ildikó



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

[openstack-dev] OpenStack Summit Berlin CFP Closes July 17

[Ashlee Ferguson]

Hi everyone,

The CFP deadline for the OpenStack Summit Berlin is less than one week away, so 
make sure to submit your talks 
 before 
July 18 at 6:59am UTC (July 17 at 11:59pm PST). 

Tracks:

• CI/CD
• Container Infrastructure
• Edge Computing
• Hands on Workshops
• HPC / GPU / AI
• Open Source Community
• Private & Hybrid Cloud
• Public Cloud
• Telecom & NFV

SUBMIT HERE 


Community voting, the first step in building the Summit schedule, will open in 
mid July. Once community voting concludes, a Programming Committee for each 
Track will build the schedule. Programming Committees are made up of 
individuals from many different open source communities working in open 
infrastructure, in addition to people who have participated in the past. Read 
the full selection process here 
.


Register for the Summit 

 - Early Bird pricing ends August 21

Become a Sponsor 


Cheers,
Ashlee


Ashlee Ferguson
OpenStack Foundation
ash...@openstack.org




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

[openstack-dev] [keystone] Stein PTG Planning Etherpad

[Lance Bragstad]

It's getting to be that time of the release (and I'm seeing other
etherpads popping up on the mailing list). I've created one specifically
for keystone [0].

Same drill as the last two PTGs. We'll start by just getting topics
written down and I'll group similar topics into buckets prior to
building a somewhat official schedule.

Please feel free to add topics you'd like to discuss at the PTG.

[0] https://etherpad.openstack.org/p/keystone-stein-ptg



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] [nova] Denver Stein ptg planning

[melanie witt]

Hello Devs and Ops,

I've created an etherpad where we can start collecting ideas for topics 
to cover at the Stein PTG. Please feel free to add your comments and 
topics with your IRC nick next to it to make it easier to discuss with you.


https://etherpad.openstack.org/p/nova-ptg-stein

Cheers,
-melanie

__
OpenStack Development Mailing 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] review runway status

[melanie witt]

Howdy everyone,

Here is the current review runway [1] status for blueprints in runways. 
Milestone r-3 (feature freeze) is coming up soon July 26, so this will 
be the last runway before FF unless we can complete some earlier than 
their end dates.


* Allow abort live migrations in queued status 
https://blueprints.launchpad.net/nova/+spec/abort-live-migration-in-queued-status 
(Kevin Zheng) [END DATE: 2018-07-25] starts here 
https://review.openstack.org/563505


* Add z/VM driver 
https://blueprints.launchpad.net/nova/+spec/add-zvm-driver-rocky 
(jichen) [END DATE: 2018-07-25] starts here 
https://review.openstack.org/523387


* Support traits in Glance 
https://blueprints.launchpad.net/nova/+spec/glance-image-traits 
(arvindn05) [END DATE: 2018-07-25] last patch 
https://review.openstack.org/569498


Best,
-melanie

[1] https://etherpad.openstack.org/p/nova-runways-rocky

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

Re: [openstack-dev] [nova] Rocky blueprint status tracking

[melanie witt]

On Fri, 15 Jun 2018 16:12:21 -0500, Matt Riedemann wrote:

On 6/15/2018 11:23 AM, melanie witt wrote:

Similar to last cycle, we have an etherpad for tracking the status of
approved nova blueprints for Rocky here:

https://etherpad.openstack.org/p/nova-rocky-blueprint-status

that we can use to help us review patches. If I've missed any blueprints
or if anything needs an update, please add a note on the etherpad and
we'll get it sorted.


Thanks for doing this, I find it very useful to get an overall picture
of where we're sitting in the final milestone.


Milestone r-3 (feature freeze) is just around the corner July 26 and 
I've refreshed the status tracking etherpad, mostly because some of the 
wayward blueprints are now ready for review. There are 3 blueprints 
which have only one patch left to merge before they're complete.


Please check out the etherpad and use it as a guide for your reviews, so 
we can complete as many blueprints as we can before FF. And please add 
notes or move/add blueprints that I might have missed.


Thanks all,
-melanie





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

[Alex Schultz]

Hello everyone,

As milestone 3 is quickly approaching, it's time to review the open
blueprints[0] and their status.  It appears that we have made good
progress on implementing significant functionality this cycle but we
still have some open items.  Below is the list of blueprints that are
still open so we'll want to see if they will make M3 and if not, we'd
like to move them out to Stein and they won't make Rocky without an
FFE.

Currently not marked implemented but without any open patches (likely
implemented):
- https://blueprints.launchpad.net/tripleo/+spec/major-upgrade-workflow
- 
https://blueprints.launchpad.net/tripleo/+spec/tripleo-predictable-ctlplane-ips

Currently open with pending patches (may need FFE):
- https://blueprints.launchpad.net/tripleo/+spec/config-download-ui
- https://blueprints.launchpad.net/tripleo/+spec/container-prepare-workflow
- https://blueprints.launchpad.net/tripleo/+spec/containerized-undercloud
- https://blueprints.launchpad.net/tripleo/+spec/bluestore
- https://blueprints.launchpad.net/tripleo/+spec/gui-node-discovery-by-range
- https://blueprints.launchpad.net/tripleo/+spec/multiarch-support
- 
https://blueprints.launchpad.net/tripleo/+spec/tripleo-routed-networks-templates
- https://blueprints.launchpad.net/tripleo/+spec/sriov-vfs-as-network-interface
- https://blueprints.launchpad.net/tripleo/+spec/custom-validations

Currently open without work (should be moved to Stein):
- https://blueprints.launchpad.net/tripleo/+spec/automated-ui-testing
- https://blueprints.launchpad.net/tripleo/+spec/plan-from-git-in-gui
- https://blueprints.launchpad.net/tripleo/+spec/tripleo-ui-react-walkthrough
- 
https://blueprints.launchpad.net/tripleo/+spec/wrapping-workflow-for-node-operations
- https://blueprints.launchpad.net/tripleo/+spec/ironic-overcloud-ci


Please take some time to review this list and update it.  If you think
you are close to finishing out the feature and would like to request
an FFE please start getting that together with appropriate details and
justifications for the FFE.

Thanks,
-Alex

[0] https://blueprints.launchpad.net/tripleo/rocky

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

[openstack-dev] FW: Change in openstack/masakari-monitors[master]: Introspective Instance Monitoring through QEMU Guest Agent

[Kwan, Louie]

Thanks again Tushar and Adam for reviewing 534958.



Anything else to get Workflow to +1?



Thanks.

Louie



-Original Message-
From: Tushar Patil (Code Review) [mailto:rev...@openstack.org]
Sent: Tuesday, July 10, 2018 10:21 PM
To: Kwan, Louie
Cc: Friesen, Chris; Tim Bell; Waines, Greg; Li Yingjun; Sampath Priyankara 
(samP); wangqiang-bj; Jean-Philippe Evrard; Young, Ken; Tushar Patil; Andrew 
Beekhof; Abhishek Kekane; zhangyangyang; takahara.kengo; Rikimaru Honjo; Dinesh 
Bhor; Michele Baldessari; Adam Spiers
Subject: Change in openstack/masakari-monitors[master]: Introspective Instance 
Monitoring through QEMU Guest Agent



Tushar Patil has posted comments on this change. ( 
https://review.openstack.org/534958 )



Change subject: Introspective Instance Monitoring through QEMU Guest Agent

..





Patch Set 9: Code-Review+2



LGTM. Thank you.



--

To view, visit https://review.openstack.org/534958

To unsubscribe, visit https://review.openstack.org/settings



Gerrit-MessageType: comment

Gerrit-Change-Id: I9efc6afc8d476003d3aa7fee8c31bcaa65438674

Gerrit-PatchSet: 9

Gerrit-Project: openstack/masakari-monitors

Gerrit-Branch: master

Gerrit-Owner: Louie Kwan 

Gerrit-Reviewer: Abhishek Kekane 

Gerrit-Reviewer: Adam Spiers 

Gerrit-Reviewer: Andrew Beekhof 

Gerrit-Reviewer: Chris Friesen 

Gerrit-Reviewer: Dinesh Bhor 

Gerrit-Reviewer: Greg Waines 

Gerrit-Reviewer: Hieu LE 

Gerrit-Reviewer: Jean-Philippe Evrard 

Gerrit-Reviewer: Ken Young 

Gerrit-Reviewer: Li Yingjun 

Gerrit-Reviewer: Louie Kwan 

Gerrit-Reviewer: Michele Baldessari 

Gerrit-Reviewer: Rikimaru Honjo 

Gerrit-Reviewer: Sampath Priyankara (samP) 

Gerrit-Reviewer: Tim Bell 

Gerrit-Reviewer: Tushar Patil 

Gerrit-Reviewer: Tushar Patil 

Gerrit-Reviewer: Zuul

Gerrit-Reviewer: takahara.kengo 

Gerrit-Reviewer: wangqiang-bj 

Gerrit-Reviewer: zhangyangyang 

Gerrit-HasComments: No
__
OpenStack Development Mailing 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] Finalizing neutron-lib release for Rocky

[Boden Russell]

Howdy,
We need to have a final release of neutron-lib for Rocky by July 19th,
so we should probably propose a neutron-lib 1.18.0 release early next week.

To help focus our review efforts between now and then I'd like to ask
folks to tag any neutron-lib patches they deem necessary for Rocky with
the string "rocky-candidate" (just add a comment with "rocky-candidate"
to the patch). This will allow us to use a query [1] to focus our
efforts in this regard.

Please keep in mind that API reference patches don't fall into this
category as they are not based on pypi releases (IIUC).

If you have any questions please feel free to reach out on the
#openstack-neutron channel.


Cheers

[1]
https://review.openstack.org/#/q/project:openstack/neutron-lib+comment:rocky-candidate

__
OpenStack Development Mailing 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] Correction: "mid-cycle" call Tuesday, July 17th - 12:00 PM UTC

[Julia Kreger]

Greetings everyone!

In my rush to get the email sent, I somehow put the wrong time on the email.

The correct date and time is Tuesday, July 17th, at 12:00 UTC.

-Julia


On Tue, Jul 10, 2018 at 12:28 PM, Julia Kreger
 wrote:
> Fellow ironicans!
>
> Lend me your ears!  With the cycle quickly coming to a close, we
> wanted to take a couple hours for high bandwidth discussions covering
> the end of cycle for Ironic, as well as any items that need to be
> established in advance of the PTG.
>
> We're going to use bluejeans[1] since it seems to work well for
> everyone, and I've posted a rough agenda[2] to an etherpad. If there
> are additional items, please feel free to add them to the etherpad.
>
> -Julia
>
> [1]: https://bluejeans.com/437242882/
> [2]: https://etherpad.openstack.org/p/ironic-rocky-midcycle

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

Re: [openstack-dev] [keystone] Adding Wangxiyuan to keystone core

[Harry Rybacki]

On Tue, Jul 10, 2018 at 6:06 PM Lance Bragstad  wrote:
>
> Hi all,
>
> Today we added Wangxiyuan to the keystone core team [0]. He's been doing
> a bunch of great work over the last couple releases and has become a
> valuable reviewer [1][2]. He's also been instrumental in pushing forward
> the unified limits work not only in keystone, but across projects.
>
> Thanks Wangxiyuan for all your help and welcome to the team!
>
+1 well deserved!

> Lance
>
> [0]
> http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-07-10-16.00.log.html#l-100
> [1] http://stackalytics.com/?module=keystone-group
> [2] http://stackalytics.com/?module=keystone-group=queens
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Harry

__
OpenStack Development Mailing 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] [zuul][openstack-infra][openstack-third-party-ci] Issues in Zuul v3 when setup 3rd party CI

[Matthieu Huin]

Hello,

Have you tried running the failing command line manually? ie

git clone ssh://lenovo_lxca...@review.openstack.org:29418/openstack/ironic
/var/lib/zuul/executor-git/review.openstack.org/openstack/ironic

(just replace the last argument by any path of your choosing)

Make sure to specify the private key you set up to authenticate on
review.openstack.org, for example using this:
https://gist.github.com/gskielian/b3f165b9a25c79f82105


This should help you pinpoint the problem.

MHU

On Wed, Jul 11, 2018 at 8:41 AM, Pei Pei2 Jia  wrote:

> Hello OpenStackers,
>
>
>
> I'm here to ask for help. I've setup zuul v3, but if fails to pull Ironic
> or other projects from gerrit. It complains "Host key verification failed".
> Some people told me that it may caused by permissions, but I've checked
> that the permission is right. Could anyone help me and have a look of it?
> The log is here http://paste.openstack.org/show/725525/, you can also
> login the VPS to investigate.
>
>
>
>
>
> Thank you
>
>
>
>
>
>
>
>
>
> *Jeremy Jia (**贾培**)*
> Software Developer, Lenovo Cloud Technology Center
> 5F, Zhangjiang Mansion, 560 SongTao Rd. Pudong, Shanghai
>
>
>   jiap...@lenovo.com
>   Ph: 8621-
>   Mobile: 8618116119081
>
>
> www.lenovo.com  / www.lenovo.com 
> Forums  | Blogs  |
> Twitter  | Facebook
>  | Flickr
> 
> Print only when necessary
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [barbican] Can we support key wrapping mechanisms other than CKM_AES_CBC_PAD?

[Lingxian Kong]

BTW, i am using `CKM_RSA_PKCS` because it's the only one of the suggested
mechanisms that SoftHSM supports according to the output of `pkcs11-tool
--module libsofthsm2.so ---slot $slot --list-mechanisms`.

*$ pkcs11-tool --module libsofthsm2.so ---slot $slot --list-mechanisms*
*...*

*RSA-PKCS, keySize={512,16384}, encrypt, decrypt, sign, verify, wrap,
unwrap*
*...*




Cheers,
Lingxian Kong

On Wed, Jul 11, 2018 at 10:48 PM, Lingxian Kong 
wrote:

> Hi Ade,
>
> Thanks for your reply.
>
> I just replaced `CKM_AES_CBC_PAD` with `CKM_RSA_PKCS` here[1], of course I
> defined `CKM_RSA_PKCS = 0x0001` in the code, but still got the
> following error:
>
> *Jul 11 10:42:05 barbican-devstack devstack@barbican-svc.service[19897]:
> 2018-07-11 10:42:05.309 19900 WARNING barbican.plugin.crypto.p11_crypto
> [req-f2d27105-4811-4c77-a321-2ac1399cc9d2 b268f84aef814ae*
> *da17ad3fa38e0049d 7abe0e02baec4df2b6046d7ef7f44998 - default default]
> Reinitializing PKCS#11 library: HSM returned response code: 0x7L
> CKR_ARGUMENTS_BAD: P11CryptoPluginException: HSM returned response code:
> 0x7L CKR_ARGUMENTS_BAD*
>
> ​[1]: https://github.com/openstack/barbican/blob/
> 5dea5cec130b59ecfb8d46435cd7eb3212894b4c/barbican/plugin/
> crypto/pkcs11.py#L496​
>
>
> Cheers,
> Lingxian Kong
>
> On Wed, Jul 11, 2018 at 9:18 PM, Ade Lee  wrote:
>
>> Lingxian,
>>
>> I don't see any reason not to provide support for other wrapping
>> mechanisms.
>>
>> Have you tried hacking the code to use one of the other wrapping
>> mechanisms to see if it works?  Ultimately, what is passed are
>> parameters to CFFI.  As long as you pass in the right input and your
>> PKCS#11 library can support it, then there should be no problem.
>>
>> If it works, it makes sense to make the wrapping algorithm configurable
>> for the plugin.
>>
>> It may or may not make sense to store the wrapping algorithm used in
>> the secret plugin-metadata if we want to support migration to other
>> HSMs.
>>
>> Ade
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [barbican] Can we support key wrapping mechanisms other than CKM_AES_CBC_PAD?

[Lingxian Kong]

Hi Ade,

Thanks for your reply.

I just replaced `CKM_AES_CBC_PAD` with `CKM_RSA_PKCS` here[1], of course I
defined `CKM_RSA_PKCS = 0x0001` in the code, but still got the
following error:

*Jul 11 10:42:05 barbican-devstack devstack@barbican-svc.service[19897]:
2018-07-11 10:42:05.309 19900 WARNING barbican.plugin.crypto.p11_crypto
[req-f2d27105-4811-4c77-a321-2ac1399cc9d2 b268f84aef814ae*
*da17ad3fa38e0049d 7abe0e02baec4df2b6046d7ef7f44998 - default default]
Reinitializing PKCS#11 library: HSM returned response code: 0x7L
CKR_ARGUMENTS_BAD: P11CryptoPluginException: HSM returned response code:
0x7L CKR_ARGUMENTS_BAD*

​[1]:
https://github.com/openstack/barbican/blob/5dea5cec130b59ecfb8d46435cd7eb3212894b4c/barbican/plugin/crypto/pkcs11.py#L496
​


Cheers,
Lingxian Kong

On Wed, Jul 11, 2018 at 9:18 PM, Ade Lee  wrote:

> Lingxian,
>
> I don't see any reason not to provide support for other wrapping
> mechanisms.
>
> Have you tried hacking the code to use one of the other wrapping
> mechanisms to see if it works?  Ultimately, what is passed are
> parameters to CFFI.  As long as you pass in the right input and your
> PKCS#11 library can support it, then there should be no problem.
>
> If it works, it makes sense to make the wrapping algorithm configurable
> for the plugin.
>
> It may or may not make sense to store the wrapping algorithm used in
> the secret plugin-metadata if we want to support migration to other
> HSMs.
>
> Ade
__
OpenStack Development Mailing 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] creating instance

[jayshankar nair]

there are lot of error lines in nova logs. But nothing related to instance 
creation. I am unable to launch instance.
 

On Tuesday, July 10, 2018 8:34 PM, Chris Friesen 
 wrote:
 

 On 07/10/2018 03:04 AM, jayshankar nair wrote:
> Hi,
>
> I  am trying to create an instance of cirros os(Project/Compute/Instances). I 
> am
> getting the following error.
>
> Error: Failed to perform requested operation on instance "cirros1", the 
> instance
> has an error status: Please try again later [Error: Build of instance
> 5de65e6d-fca6-4e78-a688-ead942e8ed2a aborted: The server has either erred or 
> is
> incapable of performing the requested operation. (HTTP 500) (Request-ID:
> req-91535564-4caf-4975-8eff-7bca515d414e)].
>
> How to debug the error.

You'll want to look at the logs for the individual service.  Since you were 
trying to create a server instance, you probably want to start with the logs 
for 
the "nova-api" service to see if there are any failure messages.  You can then 
check the logs for "nova-scheduler", "nova-conductor", and "nova-compute". 
There should be something useful in one of those.

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 Development Mailing 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] [monasca] Etharpad for Stein PTG in Denver

[Bedyk, Witold]

Hello,

I've just created an etherpad [1] for planning our sessions at the next PTG in 
Denver.
Please add the topics you'd like to discuss. The main goal of the sessions is 
to agree on development priorities and coordinate the work for the next release 
cycle.
Please also don't forget to add yourself to the attendance list, on-site or 
remote.


Cheers
Witek

[1] https://etherpad.openstack.org/p/monasca-ptg-stein

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

Re: [openstack-dev] [barbican] Can we support key wrapping mechanisms other than CKM_AES_CBC_PAD?

[Ade Lee]

Lingxian, 

I don't see any reason not to provide support for other wrapping
mechanisms.

Have you tried hacking the code to use one of the other wrapping
mechanisms to see if it works?  Ultimately, what is passed are
parameters to CFFI.  As long as you pass in the right input and your
PKCS#11 library can support it, then there should be no problem.

If it works, it makes sense to make the wrapping algorithm configurable
for the plugin.  

It may or may not make sense to store the wrapping algorithm used in
the secret plugin-metadata if we want to support migration to other
HSMs.

Ade 

On Sat, 2018-07-07 at 12:54 +1200, Lingxian Kong wrote:
> Hi Barbican guys,
> 
> Currently, I am testing the integration between Barbican and SoftHSM
> v2 but I met with a problem that SoftHSM v2 doesn't
> support CKM_AES_CBC_PAD key wrapping operation which is hardcoded in
> Barbican code here https://github.com/openstack/barbican/blob/5dea5ce
> c130b59ecfb8d46435cd7eb3212894b4c/barbican/plugin/crypto/pkcs11.py#L4
> 96. After discussion with SoftHSM team, I was told SoftHSM does
> support other mechanisms such as CKM_AES_KEY_WRAP,
> CKM_AES_KEY_WRAP_PAD, CKM_RSA_PKCS, or CKM_RSA_PKCS_OAEP.
> 
> My question is, is it easy to support other wrapping mechanisms in
> Barbican? Or if there is another workaround this problem?
> 
> Cheers,
> Lingxian Kong
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [zuul][openstack-infra][openstack-third-party-ci] Issues in Zuul v3 when setup 3rd party CI

[Pei Pei2 Jia]

Hello OpenStackers,

I'm here to ask for help. I've setup zuul v3, but if fails to pull Ironic or 
other projects from gerrit. It complains "Host key verification failed". Some 
people told me that it may caused by permissions, but I've checked that the 
permission is right. Could anyone help me and have a look of it? The log is 
here http://paste.openstack.org/show/725525/, you can also login the VPS to 
investigate.


Thank you




Jeremy Jia (贾培)
Software Developer, Lenovo Cloud Technology Center
5F, Zhangjiang Mansion, 560 SongTao Rd. Pudong, Shanghai


  jiap...@lenovo.com
  Ph: 8621-
  Mobile: 8618116119081


www.lenovo.com  / www.lenovo.com 
Forums | Blogs | 
Twitter | Facebook | 
Flickr
Print only when necessary



__
OpenStack Development Mailing 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] [OSSN-0084] Data retained after deletion of a ScaleIO volume

[Luke Hinds]

On Tue, Jul 10, 2018 at 9:08 PM, Jim Rollenhagen 
wrote:

> On Tue, Jul 10, 2018 at 3:28 PM, Martin Chlumsky <
> martin.chlum...@gmail.com> wrote:
>
>> It is the workaround that is right and the discussion part that is wrong.
>>
>> I am familiar with this bug. Using thin volumes *and/or* enabling zero
>> padding DOES ensure data contained
>> in a volume is actually deleted.
>>
>
> Great, that's super helpful. Thanks!
>
> Is there someone (Luke?) on the list that can send a correction for this
> OSSN to all the lists it needs to go to?
>
> // jim
>

It can, but I would want to be sure we get an agreed consensus. The note
has already gone through a review cycle where a cinder core approved the
contents:

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

If someone wants to put forward a patch with the needed amendments , I can
send out a correction to the lists.


>
>
>>
>> On Tue, Jul 10, 2018 at 10:41 AM Jim Rollenhagen 
>> wrote:
>>
>>> On Tue, Jul 10, 2018 at 4:20 AM, Luke Hinds  wrote:
>>>
 Data retained after deletion of a ScaleIO volume
 ---

 ### Summary ###
 Certain storage volume configurations allow newly created volumes to
 contain previous data. This could lead to leakage of sensitive
 information between tenants.

 ### Affected Services / Software ###
 Cinder releases up to and including Queens with ScaleIO volumes
 using thin volumes and zero padding.

>>>
>>> According to discussion in the bug, this bug occurs with ScaleIO volumes
>>> using thick volumes and with zero padding disabled.
>>>
>>> If the bug is with thin volumes and zero padding, then the workaround
>>> seems quite wrong. :)
>>>
>>> I'm not super familiar with Cinder, so could some Cinder folks check
>>> this out and re-issue a more accurate OSSN, please?
>>>
>>> // jim
>>>
>>>

 ### Discussion ###
 Using both thin volumes and zero padding does not ensure data contained
 in a volume is actually deleted. The default volume provisioning rule is
 set to thick so most installations are likely not affected. Operators
 can check their configuration in `cinder.conf` or check for zero padding
 with this command `scli --query_all`.

  Recommended Actions 

 Operators can use the following two workarounds, until the release of
 Rocky (planned 30th August 2018) which resolves the issue.

 1. Swap to thin volumes

 2. Ensure ScaleIO storage pools use zero-padding with:

 `scli --modify_zero_padding_policy
 (((--protection_domain_id  |
 --protection_domain_name )
 --storage_pool_name ) | --storage_pool_id )
 (--enable_zero_padding | --disable_zero_padding)`

 ### Contacts / References ###
 Author: Nick Tait
 This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0084
 Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1699573
 Mailing List : [Security] tag on openstack-dev@lists.openstack.org
 OpenStack Security Project : https://launchpad.net/~openstack-ossg


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

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


-- 
Luke Hinds | NFV Partner Engineering | CTO Office | Red Hat
e: lhi...@redhat.com | irc: lhinds @freenode | t: +44 12 52 36 2483
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev