Difference between revisions of "Meetings/Ironic"
(→Agenda for next meeting) |
(→Agenda for next meeting) |
||
Line 20: | Line 20: | ||
* Stuck specs (Specs that are stuck on contentious items. This is NOT for specs that are stuck because they aren't getting reviews.) | * Stuck specs (Specs that are stuck on contentious items. This is NOT for specs that are stuck because they aren't getting reviews.) | ||
* Discussion (Requests to have your patch reviewed should not be a 'Discussion' topic. If desired, please discuss during 'Open Discussion') | * Discussion (Requests to have your patch reviewed should not be a 'Discussion' topic. If desired, please discuss during 'Open Discussion') | ||
− | + | (lintan) should we support a new feature to accept header 'X-Openstack-Request-ID' as request_id? | |
− | + | https://review.openstack.org/#/c/238008/ | |
− | + | We have a cross spec to return 'X-Openstack-Request-Id': https://blueprints.launchpad.net/nova/+spec/cross-service-request-id | |
− | + | But I read the spec and get double confirm from other projects: | |
− | + | The spec is not asking us to accept an external passed request-id as the project’s own request-id, it only needs to return request-id. | |
− | + | http://osdir.com/ml/openstack-dev/2016-01/msg01745.html | |
− | + | So I would like to discuss two points: | |
+ | 1. Should we accept the header as request_id or just generate a request_id and append it to response headers? | ||
+ | 2. Since Neutron and Keystone didn't support accept external request_id, this is not so useful from the perspective of Ironic, do we need the feature at all? | ||
* Open Discussion | * Open Discussion | ||
Revision as of 10:04, 27 January 2016
Contents
Weekly Ironic Project Team Meeting
If you're interested in bare metal deployments within OpenStack, please join our weekly discussion about the Ironic project! The one-hour weekly meetings start at 1700 UTC on Mondays, are held in the #openstack-meeting-3
room on irc.freenode.net
, and are chaired by Jim Rollenhagen (jroll), Devananda van der Veen (devananda) or Chris Krelle (NobodyCam).
NOTE: Meeting time is UTC based and may need to be adjusted based on local time zone changes, eg. as a result of daylight savings, which changes on different days in different countries.
- ICS (Calendar) file for the meeting. You can add this to your calendar.
- Eavesdrop meeting page
Anyone is welcome to add topics to the agenda. However, topics should be posted at least two (2) days before the meeting to give folks time to get context, and should include the IRC handle of the proposer and a link to further information. This gives everyone time to review any material ahead of time so we can use the meeting time for actual discussion. Requests to have a patch reviewed should not be a topic and instead should be covered during the Open Discussion portion of the meeting.
- Example topic: (devananda) Let's talk about zebras. Reference: http://en.wikipedia.org/wiki/Zebra
Next Meeting
The next meeting will be on February 01, 2016 at 1700 UTC (http://www.timeanddate.com/worldclock/fixedtime.html?iso=20160201T1700).
Agenda for next meeting
- Announcements / Reminders
- Review subteam status reports (capped at ten minutes)
- Stuck specs (Specs that are stuck on contentious items. This is NOT for specs that are stuck because they aren't getting reviews.)
- Discussion (Requests to have your patch reviewed should not be a 'Discussion' topic. If desired, please discuss during 'Open Discussion')
(lintan) should we support a new feature to accept header 'X-Openstack-Request-ID' as request_id? https://review.openstack.org/#/c/238008/ We have a cross spec to return 'X-Openstack-Request-Id': https://blueprints.launchpad.net/nova/+spec/cross-service-request-id But I read the spec and get double confirm from other projects: The spec is not asking us to accept an external passed request-id as the project’s own request-id, it only needs to return request-id. http://osdir.com/ml/openstack-dev/2016-01/msg01745.html So I would like to discuss two points: 1. Should we accept the header as request_id or just generate a request_id and append it to response headers? 2. Since Neutron and Keystone didn't support accept external request_id, this is not so useful from the perspective of Ironic, do we need the feature at all?
- Open Discussion
Previous meetings
Logs from previous meetings can be found here.