[openstack-dev] [magnum] Any plan to resume nodegroup work?
Hi, I saw magnum nodegroup specs https://review.openstack.org/425422, https://review.openstack.org/433680, and https://review.openstack.org/425431 were last updated a year ago. is there any plan to resume this work or is it superseded by other specs or features? Thanks! Regards, Wan-yen __ 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
In Nisha's message, "capabilities" refers to "ComputeCapabilitiesFilter". "capabilities" provides a lot of flexibility for scheduling. It supports qualitative as well as quantitative attributes. It supports a variety of operators such as ">=", "<", "=", etc. For instance, with "capabilities", one can create a flavor for "GPU_Count >=2". Quantity matters for workloads. A workload may require at least 2GPUs or at least certain amount of SSD capacity to meet the performance requirements. Trait will help but it only supports qualitative attributes. Therefore, we still need "capabilities". Standard Resource Class represents quantitative things but it 's not available for Ironic. Ironic currently can only use one single CUSTOM_Resource_class with exact match. Prior to Pike, Ironic customers can use non-exact match filter to support the use case of "at least this amount of quantitative things on a bare metal node" but it's not supported by Ironic Custom_resource_class. Therefore it is a regression and will cause issues for those who are depending on it. On 19 October 2017 at 15:38, Jay Pipeswrote: > On 10/16/2017 05:31 AM, Nisha Agarwal wrote: > >> Hi Matt, >> >> As i understand John's spec https://review.openstack.org/#/c/507052/ < >> 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. >> > > Hi Nisha, > > This may be a case of mixed terminology. We do not refer to anything > quantitative as a "capability". Rather, we use the term "resource class" > (or sometimes just "resource") to represent quantitative things that may be > consumed by the instance. > > Traits, on the other hand, are qualitative. They represent a binary on/off > capability that the compute host (or baremetal node in the case of Ironic) > exposes. > > There's no limit on the number of traits that may be associated with a > particular Ironic baremetal node. However, for Ironic baremetal nodes, if > the node.resource_class attribute is set, the Nova Ironic virt driver will > create a single inventory record for the node containing a quantity of 1 > and a resource class equal to whatever is in the node.resource_class > attribute. This resource class is auto-created by Nova as a custom resource > class. > Just to follow up on this one... I hope my traits spec will replace the need for the non-exact filters. Consider two flavors Gold and Gold_Plus. Lets say Gold_plus gives you a slightly newer CPU, or something. Consider this setup: * both GOLD and GOLD_PLUS ironic nodes have Resource Class: CUSTOM_GOLD * but you can have some have trait: GOLD_REGULAR and some with GOLD_PLUS Now you can have the flavors: * GOLD flavor requests resources:CUSTOM_GOLD=1 * GOLD_PLUS flavor also has resources:CUSTOM_GOLD=1 but also trait:GOLD_PLUS:requires Now eventually we could modify the GOLD flavor to say: * resources:CUSTOM_GOLD=1 and trait:GOLD_REGULAR:prefer @Nisha I think that should largely allow you to construct the same behavior you have today, or am I totally missing what you are wanting to do? On Thu, Oct 19, 2017 at 8:37 AM, John Garbutt wrote: > On 19 October 2017 at 15:38, Jay Pipes wrote: > >> On 10/16/2017 05:31 AM, Nisha Agarwal wrote: >> >>> Hi Matt, >>> >>> As i understand John's spec https://review.openstack.org/#/c/507052/ < >>> 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. >>> >> >> Hi Nisha, >> >> This may be a case of mixed terminology. We do not refer to anything >> quantitative as a "capability". Rather, we use the term "resource class" >> (or sometimes just "resource") to represent quantitative things that may be >> consumed by the instance. >> >> Traits, on the other hand, are qualitative. They represent a binary >> on/off capability that the compute host (or baremetal node in the case of >> Ironic) exposes. >> >> There's no limit on the number of traits that may be associated with a >> particular Ironic baremetal node. However, for Ironic baremetal nodes, if >> the node.resource_class attribute is set, the Nova Ironic virt driver will >> create a single inventory record for the node containing a quantity of 1 >> and a resource class equal to whatever is in the node.resource_class >> attribute. This resource class is auto-created by Nova as a custom resource >> class. >> > > Just to
Re: [openstack-dev] [nova][ironic] Concerns over rigid resource class-only ironic scheduling
>>* Nisha is raising the question about whether or not we're making *>>* incorrect assumptions about how people are using nova/ironic and they *>>* want to use the non-Exact filters for VCPU/MEMORY_MB/DISK_GB, which as *>>* far as I have ever heard is not recommended/supported upstream as it can *>>* lead to resource tracking issues in Nova that eventually lead to *>>* scheduling failures later because of the scheduler thinking a node is *>>* available for more than one instance when it's really not. * >This came up in the Nova PTG room yesterday and I wanted to reply on the >thread with what I understood about it, for those who weren't in the >session. In general, it's recommended to use the exact filters (1 flavor >per Ironic node hardware config) as there's no concept of partially >claiming a baremetal node. >But, with the old non-exact filters, you _could_ get away with creating >fewer flavors than you have hardware configs and get "fuzzy matching" on >Ironic nodes, to get nodes whose configs are "close enough" but not >exact. This might be helpful in situations where you have some oddball >configs you don't want to have separate flavors for. >I was thinking, if it's possible to assign more than one resource class >to an Ironic node, maybe you could get similar behavior to the old >non-exact filters. So if you have an oddball config, you could tag it as >multiple resource classes that it's "close enough" to for a match. But >I'm not sure whether it's possible for an Ironic node to be tagged with >more than one resource class. >* Nisha is raising the question about whether or not we're making *>* incorrect assumptions about how people are using nova/ironic and they *>* want to use the non-Exact filters for VCPU/MEMORY_MB/DISK_GB, which as *>* far as I have ever heard is not recommended/supported upstream as it can *>* lead to resource tracking issues in Nova that eventually lead to *>* scheduling failures later because of the scheduler thinking a node is *>* available for more than one instance when it's really not. * The concern I have with one single custom resource class for an Ironic node is that it takes away some of the options that were available before, such as scheduling based on resource quantity and non-exact match filters (RamFilter, DiskFilter, and CoreFilter). Nova scheduling becomes too restrictive for Ironic. I know some users are using these options before Pike with no issues. Therefore, it's a mystery to me whether the non-exact filter for Ironic really has issues. Even if it has problems, it seems to me there are ways to address the problem. For instance, Ironic virt driver can report a node is not available if it's in active state (if it hasn't done so), or report all resources are consumed when a node is claimed. Alternatively, Nova scheduler can report all resources are consumed for an Ironic node if Nova is willing to make such change. Thanks! On Thu, Sep 7, 2017 at 12:48 PM, Nisha Agarwalwrote: > 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: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]HP proliant create logical drive not according to the target_raid_config
Hi Wangjun, Can you provide more info? What driver did you use? What's your target_raid_config? What do the logical drives look like after the configuration? Any log, server and storage hardware and firmware version info you can share? You are welcome to contact ilo_driv...@groups.ext.hpe.com for assistance. Thanks! Regards, wanyen On Wed, Jul 19, 2017 at 4:55 AM, 王俊wrote: > Hi, > > May I ask a question about RAID?I set target_raid_config before I > set the node state to ‘provide’, but when I make the node to available, the > server’s logical drive does not like my configures.I don’t know why.who can > give some help? > > 保密:本函仅供收件人使用,如阁下并非抬头标明的收件人,请您即刻删除本函,勿以任何方式使用及传播,并请您能将此误发情形通知发件人,谢谢! > > __ > 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] Ironic design summit schedule
Hi Jim, I have asked techtalk coordinator to switch my techtalk session time so there is no need to change group management session schedule. You can keep it at 2:50pm Wed.. Thanks! wanyen __ 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 design summit schedule
Hi Jim, My techtalk is supposed to finish by 2:45pm. However, techtalk schedule is not as well monitored as formal sessions so it could get delayed. That's why I was exploring whether the group management session can be switched to Thursday. Thanks! Wanyen >>* Hi Jim, *> >* Is it possible to switch Group management session to Thursday? I * *>*>* have a techtalk at 2:30pm on Wednesday and it makes it very tight for me *>* >>and Shiv to attend the group management at 2:50 pm. Since Shiv and myself *>>* are the proposer for the group management session, we want to be able to *>* attend this discussion. Thanks! * >Your talk is 2:00-2:40, correct? The reason I scheduled it at 2:50 is >because of this talk. The only other place I could put it is Thursday at >11:00, however some operators expressed more interest in the driver API >session, and they have Wednesday sessions going on. >I'd prefer if you could just walk quickly (run?) between these two - if >you think that is impossible I may be able to switch them. Let me know. :) // jim __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ironic] Driver documentation in Ironic
As mentioned in the weekly IRC, 3rd-party vendor drivers are ranked lower priority and therefore their code tend to merge at the late cycle of a release. Therefore, it leads little time for driver author to submit document and for upstream to review and approve the document. So, as the result, the 3r-party driver document could miss the release. I don't think the suggestion of code+document submission and review will help either. IMO it will slow down review process as reviewers will need to review documents for every feature comparing to one single document review after all features are landed. Hence I am concerned that it will slow down the review process and make landing vendor's driver code even harder unless upstream is willing to raise priority for vendor driver specs and code. Also, some features are inter-related and can introduce document inter-dependency if feature and documentation are bundled. Moreover, currently it is very difficult (if possible) to modify document after it got merged into a stable tree. Like defect in code, defects in document exist. For instance, some important configuration steps or pre-requisites may be missing in the document. Sometimes new firmware version has impact on vendor's drivers and it will require changes in driver's pre-requisites or configuration in order to work with the new firmware versions. These will require document changes in the stable branch. Therefore, there is a need for vendor driver author to make changes in stable branch to fix document defects, document known firmware issues and resolutions, and update information about supported firmware versions and hardware. IMO, Ramesh's option 2 & 3 will provide this kind of flexibility. Option1 will help driver document to land in time tor a release but won't enable changes to the stable branch unless upstream allow driver authors to self-approve document changes in the stable branch.It would be my preference, if PTL and upstream can work with infra to allow driver authors to self-approve changes to the stable branch. I am sincerely asking for help. Any upstream effort to allow driver's document change in stable branch and help driver document to land in new release in time will be very much appreciated. Thanks! On Thu, Oct 15, 2015 at 09:23:18PM +0530, Ramakrishnan G wrote: >* Hi All, *> >* This mail is related to driver-specific documentation in Ironic. *> >* First a bit of context. I work on iLO drivers in Ironic. Our team would *>* like to document both Ironic driver related stuff (which is related to *>* Ironic) and hardware related stuff like tested platforms, firmware *>* information, firmware issues, etc (which is not related to Ironic) in the *>* documentation. Today we keep it at two places - ironic related one in *>* ironic tree and (ironic + non-ironic) related one in wiki. It's hard for *>* both people who work on documentation and people who read this *>* documentation to update/refer information in two places. Hence we decided *>* to raise the review [0] to move the content completely to wiki. It got *>* mixed response. While some people are okay with it, but some others *>* (including our ptl :)) feel it's worth putting it in-tree and try to *>* address the problems. *> >* So what all are the problems ? *>* 1) Ability to update the driver documentation not-related to Ironic easily * >* without waiting. *>* 2) To save some core reviewers time who might not be familiar with the *>* hardware. *> >* To solve the actual problem of updating the documentation easily while *>* keeping it in-tree, I checked with infra folks if a subset of a repository *>* can be +2ed/+Aed by another group. They confirmed it's not possible *>* (unless there was a communication gap in that conversation, folks can *>* correct me if I am wrong). *> >* The following are the options that I can think of to address this: *> >* 1) Easy approvals for patches solely related to driver documentation. Once *>* the driver team feels the documentation is ready, it can be +Aed by a core *>* team member skipping the normal process of review. Of course, fixing any *>* comments that come by, but not waiting for the normal rule of 2x+2s. *> >* 2) A separate repository for driver documentation controller by driver *>* developers (a bad idea ??) *> >* 3) Allow to push driver documentation to wiki for those who wish to. *> >* Thoughts ??? * We talked about this in our IRC meeting as well, and there isn't really a good answer for "allow driver authors to merge their own docs ASAP". I'd like to see some examples of docs patches that: 1) took too long to merge, and 2) what problems that caused. // jim __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [ironic] Ironic design summit schedule
Hi Jim, Is it possible to switch Group management session to Thursday? I have a techtalk at 2:30pm on Wednesday and it makes it very tight for me and Shiv to attend the group management at 2:50 pm. Since Shiv and myself are the proposer for the group management session, we want to be able to attend this discussion. Thanks! wanyen __ 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] Driver documentation in Ironic
I fully agreed with Ramesh. There is a need for driver owners to be able to quickly update their driver’s document. Particularly, vendor's drivers have strong dependencies on their platform’s firmware. For instance, a new release of firmware may have impact on vendor’s driver and may require a specific firmware settings or some workaround in driver configuration. Therefore driver owners need to be able to update their driver documents to reflect support of firmware versions or hardware platforms, document firmware issues that have impacts to the drivers, …etc. Also, as more and more features added to the drivers and some features are related, sometimes it requires restructuring of the document to make it easier for readers to follow and understand. I would very much like to get tech writers to help my driver’s document but with current document review process and release schedule, it’s just very hard to do. As the result, document quality suffers. I really wish that we can give driver owner’s more control of their documents and be able to update their driver documents when needed. Among all 3 options listed below, I prefer 2 or 3. Please consider these options. Thanks! >The following are the options that I can think of to address this: >1) Easy approvals for patches solely related to driver documentation. Once >the driver team feels the documentation is ready, it can be +Aed by a core >team member skipping the normal process of review. Of course, fixing any >comments that come by, but not waiting for the normal rule of 2x+2s. >2) A separate repository for driver documentation controller by driver >developers (a bad idea ??) >3) Allow to push driver documentation to wiki for those who wish to. >Thoughts ??? >[0] https://review.openstack.org/#/c/225602/ __ 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] [Horizon] [UX] Wireframes for
Hi, Jarda We are already prepared for multiple drivers. If you look at the Driver field, there is a dropdown menu from which you can choose a driver and based on the selection the additional information (like IP, user, passw) will be changed. So, if iLO + Virtual Media is chosen in the dropdown menu, Horizon node managmement panel will display iLO Password and iLO user instead of IPMI user and IPMI Password? This is great! Also, myself and a few folks are working on Ironic UEFI support and we hope to land this feature in Juno (Spec is still in review state but the feature is on the Ironic Juno Prioritized list). In order to add UEFI boot feature, a Supported Boot Modes field in the hardware info is needed. The possible values are BIOS Only, UEFI Only, and BIOS+UEFI. We will need to work with you to add this field onto hardware info. There is no problem to accommodate this change in the UI once the back-end supports it. So if there is a desire to expose the feature in the UI, when there is already working back-end solution, feel free to send a patch which adds that to the HW info - it's an easy addition and the UI is prepared for such types of expansions. ok. Thanks! wanyen Hi Wan, thanks for great notes. My response is inline: On 2014/15/07 23:19, Wan-yen Hsu wrote: The Register Nodes panel uses IPMI user and IPMI Password. However, not all Ironic drivers use IPMI, for instance, some Ironic drivers will use iLO or other BMC interfaces instead of IPMI. I would like to suggest changing IPMI to BMC or IPMI/BMC to acomodate more Ironic drivers. The Driver field will reflect what power management interface (e.g., IPMI + PXE, or iLO + Virtual Media) is used so it can be used to correlate the user and password fields. We are already prepared for multiple drivers. If you look at the Driver field, there is a dropdown menu from which you can choose a driver and based on the selection the additional information (like IP, user, passw) will be changed. Also, myself and a few folks are working on Ironic UEFI support and we hope to land this feature in Juno (Spec is still in review state but the feature is on the Ironic Juno Prioritized list). In order to add UEFI boot feature, a Supported Boot Modes field in the hardware info is needed. The possible values are BIOS Only, UEFI Only, and BIOS+UEFI. We will need to work with you to add this field onto hardware info. There is no problem to accommodate this change in the UI once the back-end supports it. So if there is a desire to expose the feature in the UI, when there is already working back-end solution, feel free to send a patch which adds that to the HW info - it's an easy addition and the UI is prepared for such types of expansions. Thanks! wanyen Cheers -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] [Horizon] [UX] Wireframes for Node Management - Juno
Hi Jaromir, Excerpts from Jaromir Coufal's message of 2014-07-09 07:51:56 +: Hey folks, after few rounds of reviews and feedbacks, I am sending wireframes, which are ready for implementation in Juno: http://people.redhat.com/~jcoufal/openstack/juno/2014-07-09_nodes-ui_juno.pdf Let me know in case of any questions. This looks great! I have a couple comments- The Register Nodes panel uses IPMI user and IPMI Password. However, not all Ironic drivers use IPMI, for instance, some Ironic drivers will use iLO or other BMC interfaces instead of IPMI. I would like to suggest changing IPMI to BMC or IPMI/BMC to acomodate more Ironic drivers. The Driver field will reflect what power management interface (e.g., IPMI + PXE, or iLO + Virtual Media) is used so it can be used to correlate the user and password fields. Also, myself and a few folks are working on Ironic UEFI support and we hope to land this feature in Juno (Spec is still in review state but the feature is on the Ironic Juno Prioritized list). In order to add UEFI boot feature, a Supported Boot Modes field in the hardware info is needed. The possible values are BIOS Only, UEFI Only, and BIOS+UEFI. We will need to work with you to add this field onto hardware info. Thanks! wanyen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] Juno priorities and spec review timeline
Hi Devananda, I noticed that firmware update is not on the priority list. I thought there was strong interest in this capability. The design spec of out-of-band firmware update has been submitted https://review.openstack.org/#/c/100842/. We will address the review comments and uplaod a new version soon. Is it possible to add this item to the Juno list? Thanks! Regards, iron1 From: Devananda van der Veen devananda@gmail.com Date: Tue, Jul 1, 2014 at 3:42 AM Subject: [openstack-dev] [Ironic] Juno priorities and spec review timeline To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Hi all! We're roughly at the midway point between summit and release, and I feel that's a good time to take a look at our progress compared to the goals we set out at the design summit. To that end, I re-opened my summit notes about what features we had prioritized in Atlanta, and engaged many the core reviewers in a discussion last friday to estimate what we'll have time to review and land in the remainder of this cycle. Based on that, I've created this spreadsheet to represent those expectations and our current progress towards what we think we can achieve this cycle: https://docs.google.com/spreadsheets/d/1Hxyfy60hN_Fit0b-plsPzK6yW3ePQC5IfwuzJwltlbo Aside from several cleanup- and test-related tasks, these goals correlate to spec reviews that have already been proposed. I've crossed off ones which we discussed at the summit, but for which no proposal has yet been submitted. The spec-review team and I will be referring to this to help us prioritize specs reviews. While I am not yet formally blocking proposals which do not fit within this list of priorities, the review team is working with a large back-log and probably won't have time to review anything else this cycle. If you're concerned that you won't be able to land your favorite feature in Juno, the best thing you can do is to participate in reviewing other people's code, join the core team, and help us accelerate the development process of K. Borrowing a little from Nova's timeline, I have proposed the following timeline for Ironic. Note that dates listed are Thursdays, and numbers in parentheses are weeks until feature freeze. You may also note that I'll be offline for two weeks immediately prior to the Juno-3 milestone, which is another reason why I'd like the core review team to have a solid plan (read: approved specs) in place by Aug 14. July 3 (-9): spec review day on Wednesday (July 2) focus on landing specs for our priorities: https://docs.google.com/spreadsheets/d/1Hxyfy60hN_Fit0b-plsPzK6yW3ePQC5IfwuzJwltlbo Jul 24 (-6): Juno-2 milestone tagged new spec proposal freeze Jul 31 (-5): midcycle meetup (July 27-30) https://wiki.openstack.org/wiki/Sprints/BeavertonJunoSprint Aug 14 (-3): last spec review day on Wednesday (Aug 13) Aug 21 (-2): PTL offline all week Aug 28 (-1): PTL offline all week Sep 4 ( 0): Juno-3 milestone tagged Feature freeze K opens for spec proposals Unmerged J spec proposals must rebase on K Merged J specs with no code proposed are deleted and may be re-proposed for K Merged J specs with code proposed need to be reviewed for feature-freeze-exception Sep 25 (+3): RC 1 build expected K spec reviews start Oct 16 (+6): Release! Oct 30 (+8): K summit spec proposal freeze K summit sessions should have corresponding spec proposal Nov 6 (+9): K design summit Thanks! Devananda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev