<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;color:#351c75">Hi Paul, </div><div class="gmail_default" style="font-family:verdana,sans-serif;color:#351c75"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;color:#351c75">Thank you for the pointers,I am looking into the code and as you suggested I feel utilization based schedulers using monitors is the way to go. Thank you once again.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div>Regards,</div>Rahul U Nair <br> </div></div></div>
<br><div class="gmail_quote">On Wed, Oct 21, 2015 at 7:00 AM,  <span dir="ltr"><<a href="mailto:openstack-dev-request@lists.openstack.org" target="_blank">openstack-dev-request@lists.openstack.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send OpenStack-dev mailing list submissions to<br>
        <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
        <a href="mailto:openstack-dev-request@lists.openstack.org">openstack-dev-request@lists.openstack.org</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:openstack-dev-owner@lists.openstack.org">openstack-dev-owner@lists.openstack.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of OpenStack-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
   1. Re: [infra][all] Reviews with a prio label? (Markus Zoeller)<br>
   2. Re: [Nova] Migration state machine proposal. (Tang Chen)<br>
   3. Re: [release] establishing release liaisons for   mitaka<br>
      (Lingxian Kong)<br>
   4. Re: [Fuel] Assigning VIPs on network config       serialization<br>
      (Roman Prykhodchenko)<br>
   5. Re: [Fuel][Plugins] Plugin deployment questions (Igor Kalnitsky)<br>
   6. Re: [release] establishing release liaisons for   mitaka<br>
      (Renat Akhmerov)<br>
   7. Re: [Neutron] HenryG addition to the Neutron      Drivers team<br>
      (Ihar Hrachyshka)<br>
   8. Re: [infra] Upgrade to Gerrit 2.11 (Daniel P. Berrange)<br>
   9. Re: [Fuel][Plugins] Plugin deployment questions (Dmitriy Shulyak)<br>
  10. Re: [mistral] How to call 3rd-party tools(such    as      Ansible) in<br>
      Mistral (WANG, Ming Hao (Tony T))<br>
  11. Re: [Fuel][Plugins] Plugin deployment questions (Igor Kalnitsky)<br>
  12. Re: [Fuel][Plugins] Plugin deployment questions (Dmitriy Shulyak)<br>
  13. Re: [Fuel][Plugins] Plugin deployment questions (Igor Kalnitsky)<br>
  14. Re: [Neutron] HenryG addition to the Neutron      Drivers team<br>
      (Paul Michali)<br>
  15. [ANNOUNCE] [HA] [Pacemaker] new, maintained<br>
      openstack-resource-agents repository (Adam Spiers)<br>
  16. [Manila] Share allow/deny by shared secret (John Spray)<br>
  17. Re: Custom Nova scheduler based on CPU queue length<br>
      (Murray, Paul (HP Cloud))<br>
  18. Re: [Fuel][Plugins] Plugin deployment questions (Patrick Petit)<br>
  19. Re: [Neutron] Gerrit permissions and Merge rights (Gal Sagie)<br>
  20. [release][stable][ironic] ironic-inspector release        2.2.2<br>
      (liberty) (Dmitry Tantsur)<br>
  21. Re: openstack-barbican-authenticate-keystone-barbican-command<br>
      (Dave McCowan (dmccowan))<br>
  22. [magnum] k8s api tls_enabled mode testing (Qiao, Liyong)<br>
  23. Re: [Fuel][Plugins] Plugin deployment questions (Dmitriy Shulyak)<br>
  24.  [Fuel] shotgun code freeze (Vladimir Kozhukalov)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Wed, 21 Oct 2015 10:18:57 +0200<br>
From: "Markus Zoeller" <<a href="mailto:mzoeller@de.ibm.com">mzoeller@de.ibm.com</a>><br>
To: "OpenStack Development Mailing List \(not for usage questions\)"<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [infra][all] Reviews with a prio label?<br>
Message-ID:<br>
        <<a href="mailto:201510210823.t9L8NmPe010065@d06av07.portsmouth.uk.ibm.com">201510210823.t9L8NmPe010065@d06av07.portsmouth.uk.ibm.com</a>><br>
Content-Type: text/plain; charset="US-ASCII"<br>
<br>
Zaro <<a href="mailto:zaro0508@gmail.com">zaro0508@gmail.com</a>> wrote on 10/20/2015 07:49:13 PM:<br>
<br>
> From: Zaro <<a href="mailto:zaro0508@gmail.com">zaro0508@gmail.com</a>><br>
> To: "OpenStack Development Mailing List (not for usage questions)"<br>
> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
> Date: 10/20/2015 07:54 PM<br>
> Subject: Re: [openstack-dev] [infra][all] Reviews with a prio label?<br>
><br>
> Upstream Gerrit has been working on a tagging feature for a while now.<br>
> Take a look at the gerrit discussion thread[1] if you want more info<br>
> on how it came about.   They decided to call it 'hashtag' or '#' (the<br>
> name being very controversial).    Looks like some of the feature is<br>
> in Gerrit 2.11 already[2] but it's definitely still work in progress<br>
> with sparse documentation thus far.  I believe it should be fully<br>
> available in the 2.12 release and you can track it with<br>
> topic:hashtag[3] on upstream.<br>
><br>
> [1]<br>
<a href="https://groups.google.com/d/msg/repo-discuss/-dHTaWt_LJA/JwUGeCPDpTUJ" rel="noreferrer" target="_blank">https://groups.google.com/d/msg/repo-discuss/-dHTaWt_LJA/JwUGeCPDpTUJ</a><br>
>  and<br>
<a href="https://groups.google.com/d/msg/repo-discuss/jZ0raMyuiG0/YlntREKG0FgJ" rel="noreferrer" target="_blank">https://groups.google.com/d/msg/repo-discuss/jZ0raMyuiG0/YlntREKG0FgJ</a><br>
> [2] <a href="https://review-dev.openstack.org/Documentation/config-" rel="noreferrer" target="_blank">https://review-dev.openstack.org/Documentation/config-</a><br>
> hooks.html#_hashtags_changed<br>
> [3] <a href="https://gerrit-review.googlesource.com/#/q/topic:hashtags" rel="noreferrer" target="_blank">https://gerrit-review.googlesource.com/#/q/topic:hashtags</a><br>
<br>
Thanks! I've searched for "labels", "tags" and "categorization". It<br>
would never have occured to me to search for "hashtag". I'll play<br>
around with my local Gerrit 2.11 installation and let you know<br>
about the results.<br>
<br>
Regards, Markus Zoeller (markus_z)<br>
<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 21 Oct 2015 16:22:15 +0800<br>
From: Tang Chen <<a href="mailto:tangchen@cn.fujitsu.com">tangchen@cn.fujitsu.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Nova] Migration state machine proposal.<br>
Message-ID: <<a href="mailto:56274B37.10508@cn.fujitsu.com">56274B37.10508@cn.fujitsu.com</a>><br>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed<br>
<br>
Hi,<br>
<br>
Please help to take a look at this problem. I was trying to raise it in<br>
the spec discussion.<br>
But since we don't need a spec on this problem, so I want to discuss it<br>
here.<br>
It is about what the new state machine will be.<br>
<br>
<a href="http://paste.openstack.org/show/476954/" rel="noreferrer" target="_blank">http://paste.openstack.org/show/476954/</a><br>
<br>
Thanks.<br>
<br>
<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Wed, 21 Oct 2015 16:42:32 +0800<br>
From: Lingxian Kong <<a href="mailto:anlin.kong@gmail.com">anlin.kong@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [release] establishing release liaisons<br>
        for     mitaka<br>
Message-ID:<br>
        <CALjNAZ0-jdVLpEOAHs4JC71YwpQaYsxTD0t-s+7d0Kdrnx=<a href="mailto:ycw@mail.gmail.com">ycw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Hi, Doug,<br>
<br>
After conversition with Mistral PTL(Renat), I'm willing to be mistral<br>
liaison to take participate in cross-project release effort on beharf<br>
of mistral team, so please count me in.<br>
<br>
On Wed, Oct 14, 2015 at 11:25 PM, Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>> wrote:<br>
> As with the other cross-project teams, the release management team<br>
> relies on liaisons from each project to be available for coordination of<br>
> work across all teams. It's the start of a new cycle, so it's time to<br>
> find those liaison volunteers.<br>
><br>
> We are working on updating the release documentation as part of the<br>
> Project Team Guide. Release liaison responsibilities are documented in<br>
> [0], and we will update that page with more details over time.<br>
><br>
> In the past we have defaulted to having the PTL act as liaison if no<br>
> alternate is specified, and we will continue to do that during Mitaka.<br>
> If you plan to delegate release work to a liaison, especially for<br>
> submitting release requests, please update the wiki [1] to provide their<br>
> contact information. If you plan to serve as your team's liaison, please<br>
> add your contact details to the page.<br>
><br>
> Thanks,<br>
> Doug<br>
><br>
> [0] <a href="http://docs.openstack.org/project-team-guide/release-management.html#release-liaisons" rel="noreferrer" target="_blank">http://docs.openstack.org/project-team-guide/release-management.html#release-liaisons</a><br>
> [1] <a href="https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management</a><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
--<br>
Regards!<br>
-----------------------------------<br>
Lingxian Kong<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Wed, 21 Oct 2015 10:45:20 +0200<br>
From: Roman Prykhodchenko <<a href="mailto:me@romcheg.me">me@romcheg.me</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Fuel] Assigning VIPs on network config<br>
        serialization<br>
Message-ID: <BLU436-SMTP1222B9C822DD81FC85B50CDAD380@phx.gbl><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Then we should close [1] as invalid, shoudn?t we?<br>
<br>
> 20 ????. 2015 ?. ? 15:55 Igor Kalnitsky <<a href="mailto:ikalnitsky@mirantis.com">ikalnitsky@mirantis.com</a>> ???????(??):<br>
><br>
> Roman,<br>
><br>
>> This behavior is actually described in [1]. Should we allocate<br>
>> VIPs on network check as well?<br>
><br>
> No, we shouldn't. We should check whether it's enough IPs for nodes /<br>
> VIPs with current network configuration, but no more.<br>
><br>
> - igor<br>
><br>
> On Tue, Oct 20, 2015 at 4:54 PM, Igor Kalnitsky <<a href="mailto:ikalnitsky@mirantis.com">ikalnitsky@mirantis.com</a>> wrote:<br>
>> Andrew,<br>
>><br>
>>> but the problem lies that VIP's need to already be allocated.<br>
>><br>
>> Why? Fuel doesn't use them on this stage.<br>
>><br>
>><br>
>>> They need to be allocated on network update, or when a node role requiring<br>
>>> one is added to the environment.<br>
>><br>
>> It looks like either you or me misunderstood something. AFAIK, node<br>
>> role itself has nothing in common with VIPs. It doesn't require any of<br>
>> them.<br>
>><br>
>> Currently VIPs are requested by network roles, and network roles are<br>
>> the same for all nodes (except Network Templating case). Network roles<br>
>> are assigned on network, and if VIP is required for network role it<br>
>> will be allocated in the assigned network.<br>
>><br>
>> So basically, it requires a huge effort to redesign our allocation<br>
>> system to achieve what you want, because:<br>
>><br>
>> * Each time you reassign network role, the corresponding VIP should be<br>
>> re-allocated in the database either.<br>
>> * Each time you enable/disable plugins, the VIPs should be<br>
>> re-allocated, because plugins may export network roles.<br>
>> * Each time you add new node to cluster, the VIPs should be<br>
>> re-allocated, because with new node you simply may run out of free<br>
>> IPs. And, btw, should we assign IP on added nodes here? Or maybe<br>
>> postpone to serialization step?<br>
>><br>
>> Well, Andrew, I believe we don't have enough resources to implement<br>
>> your proposal. Moreover, the proposed approach requires a lot of<br>
>> discussions and design meetings. And it definitely should be<br>
>> implemented in scope of some blueprint, not a bugfix.<br>
>><br>
>><br>
>>> Not knowing the address until serialization for deployment is too late.<br>
>><br>
>> Once again - why? I agree, perhaps it would be useful, but there's no<br>
>> strict requirement on this and we should resolve our issues<br>
>> step-by-step. See my response above.<br>
>><br>
>><br>
>>> No, Again, this is too late.<br>
>><br>
>> Too late for what?<br>
>><br>
>><br>
>> - Igor<br>
>><br>
>> On Tue, Oct 20, 2015 at 12:38 PM, Roman Prykhodchenko <<a href="mailto:me@romcheg.me">me@romcheg.me</a>> wrote:<br>
>>> My concern here is that there is also a Network check feature that according to its name should check things like whether or not there?s enough IP addresses in all ranges in a network. The problem is that it may be run at any time, even when VIPs are not yet allocated. From a user-side the workflow may look a little wrong:<br>
>>><br>
>>> 1. Check network => get "Everything is fine"<br>
>>> 2. Right after that press Apply Changes => get "Network configuration is bad"<br>
>>><br>
>>> This behavior is actually described in [1]. Should we allocate VIPs on network check as well?<br>
>>><br>
>>><br>
>>> 1. <a href="https://bugs.launchpad.net/fuel/+bug/1487996" rel="noreferrer" target="_blank">https://bugs.launchpad.net/fuel/+bug/1487996</a><br>
>>><br>
>>><br>
>>> - romcheg<br>
>>><br>
>>><br>
>>>> 19 ????. 2015 ?. ? 18:28 Igor Kalnitsky <<a href="mailto:ikalnitsky@mirantis.com">ikalnitsky@mirantis.com</a>> ???????(??):<br>
>>>><br>
>>>> Hi Roman,<br>
>>>><br>
>>>>> Not assign addresses to VIPs is a network configuration is being<br>
>>>>> serialized for API output.<br>
>>>><br>
>>>> AFAIK, that's not truth. Fuel UI and OSTF relies only on *public* VIP.<br>
>>>> So we can keep only *public* VIP, and do not assign / show others.<br>
>>>><br>
>>>>> Check number of IP addresses wherever it is possible to "spoil" network<br>
>>>>> configuration: when a role get?s assigned to a node, when network<br>
>>>>> changes or network templates are applied.<br>
>>>><br>
>>>> It won't work that way. What if you enable plugin when all roles are<br>
>>>> assigned? What if you change networks, and now it's not enough IPs? Or<br>
>>>> what if enable plugin that requires 5 VIPs in public network by<br>
>>>> default, and it's not enough. But by using network templates you<br>
>>>> assign this netrole to management network?<br>
>>>><br>
>>>> From what I can say the proposed approach requires to put checks<br>
>>>> here-and-there around the code. Let's do not overcomplicate things<br>
>>>> without real need.<br>
>>>><br>
>>>> So let me share my thoughts regarding this issue.<br>
>>>><br>
>>>> * We shouldn't *allocate* VIPs when we make GET request on network<br>
>>>> configuration handler. It should return only *already allocated* VIPs<br>
>>>> and no more.<br>
>>>> * VIP allocation should be performed when we run deployment.<br>
>>>> * Before deployment checks should fail, if there's not enough VIPs or<br>
>>>> other resources. So users fix them, and try again.<br>
>>>> * Both Fuel UI and OSTF needs VIPs only when cluster is deployed, and<br>
>>>> it's safe to return allocated VIPs on that stage.<br>
>>>><br>
>>>> So what do you think guys?<br>
>>>><br>
>>>> Thanks,<br>
>>>> Igor<br>
>>>><br>
>>>> On Fri, Oct 16, 2015 at 5:25 PM, Roman Prykhodchenko <<a href="mailto:me@romcheg.me">me@romcheg.me</a>> wrote:<br>
>>>>> Hi folks!<br>
>>>>><br>
>>>>> I?ve been discussing several bugs [1-3] with some folks and noticed that they share the same root cause which is that network serialization fails, if there?s not enough IP addresses in all available ranges of one of the available networks to assign them to all VIPs. There are several possible solutions for this issue:<br>
>>>>><br>
>>>>> a. Not assign addresses to VIPs is a network configuration is being serialized for API output.<br>
>>>>> A lot of external tools and modules, i. e., OSTF, rely on that information so this relatively small change in Nailgun will require big cross-components changes. Therefore this change can only be done as a feature but it seems to be the way this issue must be fixed.<br>
>>>>><br>
>>>>> b. Leave some VIPs without IP addresses<br>
>>>>> If network configuration is generated for API output it is possible to leave some VIPs without IP addresses assigned. This will only create more mess around Nailgun and bring more issues that it will resolve.<br>
>>>>><br>
>>>>> c. Check number of IP addresses wherever it is possible to "spoil" network configuration: when a role get?s assigned to a node, when network changes or network templates are applied.<br>
>>>>><br>
>>>>><br>
>>>>> The proposal is to follow [c] as a fast solution and file a blueprint for [a]. Opinions?<br>
>>>>><br>
>>>>><br>
>>>>> 1 <a href="https://bugs.launchpad.net/fuel/+bug/1487996" rel="noreferrer" target="_blank">https://bugs.launchpad.net/fuel/+bug/1487996</a><br>
>>>>> 2 <a href="https://bugs.launchpad.net/fuel/+bug/1500394" rel="noreferrer" target="_blank">https://bugs.launchpad.net/fuel/+bug/1500394</a><br>
>>>>> 3 <a href="https://bugs.launchpad.net/fuel/+bug/1504572" rel="noreferrer" target="_blank">https://bugs.launchpad.net/fuel/+bug/1504572</a><br>
>>>>><br>
>>>>><br>
>>>>> - romcheg<br>
>>>>><br>
>>>>> __________________________________________________________________________<br>
>>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>><br>
>>>><br>
>>>> __________________________________________________________________________<br>
>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>>><br>
>>> __________________________________________________________________________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 842 bytes<br>
Desc: Message signed with OpenPGP using GPGMail<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20151021/297a827f/attachment-0001.pgp" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20151021/297a827f/attachment-0001.pgp</a>><br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Wed, 21 Oct 2015 11:46:12 +0300<br>
From: Igor Kalnitsky <<a href="mailto:ikalnitsky@mirantis.com">ikalnitsky@mirantis.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Fuel][Plugins] Plugin deployment<br>
        questions<br>
Message-ID:<br>
        <CACo6NWDv_kC00sNcD+TZdq6qWe91hmv=<a href="mailto:nhmRKuM6fj2E6J_Trw@mail.gmail.com">nhmRKuM6fj2E6J_Trw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Hey Mike,<br>
<br>
AFAIK, there's no bug/blueprint on LP.<br>
<br>
The question I want to raise here is what will happen if I decide to<br>
deploy a cluster with one compute without controllers? It looks like a<br>
bad UX to me, though it may increase speed of CI gates where one node<br>
with one role is enough.<br>
<br>
Can we ignore the problem above and remove this limitation? Or should<br>
we improve it somehow so it would work for one nodes, and will be<br>
ignored for others?<br>
<br>
Thanks,<br>
Igor<br>
<br>
On Wed, Oct 21, 2015 at 9:04 AM, Mike Scherbakov<br>
<<a href="mailto:mscherbakov@mirantis.com">mscherbakov@mirantis.com</a>> wrote:<br>
> Hi all,<br>
> is there a plan to remove this restriction permanently? Any bug/blueprint<br>
> covering it?<br>
><br>
> On Tue, Oct 20, 2015 at 5:07 AM Patrick Petit <<a href="mailto:ppetit@mirantis.com">ppetit@mirantis.com</a>> wrote:<br>
>><br>
>> Hi Matthew,<br>
>><br>
>> That?s useful.<br>
>> Thanks<br>
>><br>
>> On 20 Oct 2015 at 11:22:07, Matthew Mosesohn (<a href="mailto:mmosesohn@mirantis.com">mmosesohn@mirantis.com</a>)<br>
>> wrote:<br>
>><br>
>> Hi Patrick,<br>
>><br>
>> During the 7.0 development cycle we made a lot of enhancements to what<br>
>> environment characteristics can be modified through a plugin. One item that<br>
>> plugins cannot directly modify is the default Fuel roles and their metadata.<br>
>> That having been said, there is an open-ended post_install.sh script you can<br>
>> use for your plugin to "hack" this value. I know of one project that<br>
>> currently disables the requirement for controller role in a deployment. This<br>
>> may be helpful in testing a given standalone role that doesn't depend on a<br>
>> controller.<br>
>><br>
>> Here's a link to the script: <a href="http://paste.openstack.org/show/476821/" rel="noreferrer" target="_blank">http://paste.openstack.org/show/476821/</a><br>
>> Note that this doesn't reflect "enabled" status of a plugin. It will make<br>
>> controller min count 0 for all environments. That won't break them, but it<br>
>> just removes the restriction.<br>
>><br>
>> Best Regards,<br>
>> Matthew Mosesohn<br>
>><br>
>> On Mon, Oct 19, 2015 at 3:29 PM, Dmitry Mescheryakov<br>
>> <<a href="mailto:dmescheryakov@mirantis.com">dmescheryakov@mirantis.com</a>> wrote:<br>
>>><br>
>>> Hello folks,<br>
>>><br>
>>> I second Patrick's idea. In our case we would like to install standalone<br>
>>> RabbitMQ cluster with Fuel reference architecture to perform destructive<br>
>>> tests on it. Requirement to install controller is an excessive burden in<br>
>>> that case.<br>
>>><br>
>>> Thanks,<br>
>>><br>
>>> Dmitry<br>
>>><br>
>>> 2015-10-19 13:44 GMT+03:00 Patrick Petit <<a href="mailto:ppetit@mirantis.com">ppetit@mirantis.com</a>>:<br>
>>>><br>
>>>> Hi There,<br>
>>>><br>
>>>> There are situations where we?d like to deploy only Fuel plugins in an<br>
>>>> environment.<br>
>>>> That?s typically the case with Elasticsearch and InfluxDB plugins of LMA<br>
>>>> tools.<br>
>>>> Currently it?s not possible because you need to at least have one<br>
>>>> controller.<br>
>>>> What exactly is making that limitation? How hard would it be to have it<br>
>>>> removed?<br>
>>>><br>
>>>> Thanks<br>
>>>> Patrick<br>
>>>><br>
>>>><br>
>>>> __________________________________________________________________________<br>
>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>> Unsubscribe:<br>
>>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>><br>
>>><br>
>>><br>
>>><br>
>>> __________________________________________________________________________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe:<br>
>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> --<br>
> Mike Scherbakov<br>
> #mihgen<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Wed, 21 Oct 2015 14:46:43 +0600<br>
From: Renat Akhmerov <<a href="mailto:rakhmerov@mirantis.com">rakhmerov@mirantis.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [release] establishing release liaisons<br>
        for     mitaka<br>
Message-ID: <<a href="mailto:4F5BF664-2A58-42CE-BF67-7C40D199AEB9@mirantis.com">4F5BF664-2A58-42CE-BF67-7C40D199AEB9@mirantis.com</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
<br>
> On 21 Oct 2015, at 14:42, Lingxian Kong <<a href="mailto:anlin.kong@gmail.com">anlin.kong@gmail.com</a>> wrote:<br>
><br>
> Hi, Doug,<br>
><br>
> After conversition with Mistral PTL(Renat), I'm willing to be mistral<br>
> liaison to take participate in cross-project release effort on beharf<br>
> of mistral team, so please count me in.<br>
<br>
Yes, I confirm.<br>
<br>
Renat Akhmerov<br>
@ Mirantis Inc.<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Wed, 21 Oct 2015 11:01:44 +0200<br>
From: Ihar Hrachyshka <<a href="mailto:ihrachys@redhat.com">ihrachys@redhat.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Neutron] HenryG addition to the Neutron<br>
        Drivers team<br>
Message-ID: <<a href="mailto:E32ADD66-F944-4B47-A37E-1050AE24F98B@redhat.com">E32ADD66-F944-4B47-A37E-1050AE24F98B@redhat.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
<br>
> On 21 Oct 2015, at 05:14, Armando M. <<a href="mailto:armamig@gmail.com">armamig@gmail.com</a>> wrote:<br>
><br>
> Hi folks,<br>
><br>
> Henry has been instrumental in many areas of the projects and his crazy working hours makes even Kevin and I bow in awe.<br>
><br>
> Jokes aside, I would like to announce HenryG as a new member of the Neutron Drivers team.<br>
><br>
> Having a propension to attendance, and desire to review of RFEs puts you on the right foot to join the group, whose members are rotated regularly so that everyone is given the opportunity to grow, and no-one burns out.<br>
><br>
> The team [1] meets regularly on Tuesdays [2], and anyone is welcome to attend.<br>
><br>
> Please, join me in welcome Henry to the team.<br>
<br>
Nice addition. :)<br>
<br>
Do we have criteria for neutron-drivers team members documented? Or is it a mere ?regularly attending the meetings, be mindful and apply common sense??<br>
<br>
Ihar<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 455 bytes<br>
Desc: Message signed with OpenPGP using GPGMail<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20151021/0b715653/attachment-0001.pgp" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20151021/0b715653/attachment-0001.pgp</a>><br>
<br>
------------------------------<br>
<br>
Message: 8<br>
Date: Wed, 21 Oct 2015 10:29:50 +0100<br>
From: "Daniel P. Berrange" <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [infra] Upgrade to Gerrit 2.11<br>
Message-ID: <<a href="mailto:20151021092949.GB21888@redhat.com">20151021092949.GB21888@redhat.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
On Tue, Oct 13, 2015 at 05:08:29PM -0700, Zaro wrote:<br>
> Hello All,<br>
><br>
> The openstack-infra team would like to upgrade from our Gerrit 2.8 to<br>
> Gerrit 2.11.  We are proposing to do the upgrade shortly after the<br>
> Mitaka summit.  The main motivation behind the upgrade is to allow us<br>
> to take advantage of some of the new REST api, ssh commands, and<br>
> stream events features.  Also we wanted to stay closer to upstream so<br>
> it will be easier to pick up more recent features and fixes.<br>
<br>
Looking at the release notes I see my most wanted new feature, keyword<br>
tagging of changes, is available<br>
<br>
[quote]<br>
Hashtags.<br>
<br>
Hashtags can be added to changes. The hashtags are stored in git notes and<br>
are indexed in the secondary index.<br>
<br>
This feature requires the notedb to be enabled.<br>
[/quote]<br>
<br>
It is listed as an experimental feature, but I'd really love to see this<br>
enabled if at all practical.<br>
<br>
Regards,<br>
Daniel<br>
--<br>
|: <a href="http://berrange.com" rel="noreferrer" target="_blank">http://berrange.com</a>      -o-    <a href="http://www.flickr.com/photos/dberrange/" rel="noreferrer" target="_blank">http://www.flickr.com/photos/dberrange/</a> :|<br>
|: <a href="http://libvirt.org" rel="noreferrer" target="_blank">http://libvirt.org</a>              -o-             <a href="http://virt-manager.org" rel="noreferrer" target="_blank">http://virt-manager.org</a> :|<br>
|: <a href="http://autobuild.org" rel="noreferrer" target="_blank">http://autobuild.org</a>       -o-         <a href="http://search.cpan.org/~danberr/" rel="noreferrer" target="_blank">http://search.cpan.org/~danberr/</a> :|<br>
|: <a href="http://entangle-photo.org" rel="noreferrer" target="_blank">http://entangle-photo.org</a>       -o-       <a href="http://live.gnome.org/gtk-vnc" rel="noreferrer" target="_blank">http://live.gnome.org/gtk-vnc</a> :|<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 9<br>
Date: Wed, 21 Oct 2015 12:51:03 +0300<br>
From: Dmitriy Shulyak <<a href="mailto:dshulyak@mirantis.com">dshulyak@mirantis.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Fuel][Plugins] Plugin deployment<br>
        questions<br>
Message-ID:<br>
        <<a href="mailto:CAP2-cGfvtSCyMyvnQ%2BQug9c_wtX76D9O0VpPmhbbBo-deFepLQ@mail.gmail.com">CAP2-cGfvtSCyMyvnQ+Qug9c_wtX76D9O0VpPmhbbBo-deFepLQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi,<br>
<br>
Can we ignore the problem above and remove this limitation? Or should<br>
> we improve it somehow so it would work for one nodes, and will be<br>
> ignored for others?<br>
><br>
I think that this validation needs to be accomplished in a different way,<br>
we don't need 1 controller for the sake of 1 controller,<br>
1 controller is a dependency of compute/cinder/other roles. So from my pov<br>
there is atleast 2 options:<br>
<br>
1. Use tasks dependencies, and prevent deployment in case if some tasks<br>
relies on controller.<br>
But the implementation might be complicated<br>
<br>
2. Insert required metadata into roles that relies on another roles, for<br>
compute it will be something like:<br>
   compute:<br>
     requires: controller > 1<br>
We actually have DSL for declaring such things, we just need to specify<br>
this requirements from other side.<br>
<br>
But in 2nd case we will still need to use tricks, like one provided by<br>
Matt, for certain plugins. So maybe we should spend time and do 1st.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20151021/15385215/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20151021/15385215/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 10<br>
Date: Wed, 21 Oct 2015 09:54:32 +0000<br>
From: "WANG, Ming Hao (Tony T)" <<a href="mailto:tony.a.wang@alcatel-lucent.com">tony.a.wang@alcatel-lucent.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [mistral] How to call 3rd-party<br>
        tools(such      as      Ansible) in Mistral<br>
Message-ID:<br>
        <<a href="mailto:F1F484A52BD63243B5497BFC9DE26E5A6F1A0728@SG70YWXCHMBA05.zap.alcatel-lucent.com">F1F484A52BD63243B5497BFC9DE26E5A6F1A0728@SG70YWXCHMBA05.zap.alcatel-lucent.com</a>><br>
<br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Renat,<br>
<br>
Thanks for your valuable suggestions!<br>
<br>
Tony<br>
<br>
From: Renat Akhmerov [mailto:<a href="mailto:rakhmerov@mirantis.com">rakhmerov@mirantis.com</a>]<br>
Sent: Wednesday, October 21, 2015 2:35 PM<br>
To: OpenStack Development Mailing List (not for usage questions)<br>
Subject: Re: [openstack-dev] [mistral] How to call 3rd-party tools(such as Ansible) in Mistral<br>
<br>
<br>
On 20 Oct 2015, at 14:58, WANG, Ming Hao (Tony T) <<a href="mailto:tony.a.wang@alcatel-lucent.com">tony.a.wang@alcatel-lucent.com</a><mailto:<a href="mailto:tony.a.wang@alcatel-lucent.com">tony.a.wang@alcatel-lucent.com</a>>> wrote:<br>
<br>
Another question is:<br>
If I use custom action to run Ansible, the Ansible playbook should be stored on the same server of Mistral. Is it right?<br>
<br>
Depends on how this action is implemented (it can, for example, do ssh to other servers) but the simplest implementation would be with playbooks on the same server, yes.<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20151021/47960d2d/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20151021/47960d2d/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 11<br>
Date: Wed, 21 Oct 2015 13:01:22 +0300<br>
From: Igor Kalnitsky <<a href="mailto:ikalnitsky@mirantis.com">ikalnitsky@mirantis.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Fuel][Plugins] Plugin deployment<br>
        questions<br>
Message-ID:<br>
        <CACo6NWC-bcV0d2cq=<a href="mailto:DA%2BsFae%2BW-XFsg3pDWgaKm8dstYkxrRgw@mail.gmail.com">DA+sFae+W-XFsg3pDWgaKm8dstYkxrRgw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Hi Dmitry,<br>
<br>
> Insert required metadata into roles that relies on another roles, for<br>
> compute it will be something like:<br>
><br>
>     compute:<br>
>         requires: controller > 1<br>
<br>
Yeah, that's actually what I was thinking about when I wrote:<br>
<br>
> Or should we improve it somehow so it would work for one nodes,<br>
> and will be ignored for others?<br>
<br>
So I'm +1 for extending our meta information with such dependencies.<br>
<br>
Sincerely,<br>
Igor<br>
<br>
On Wed, Oct 21, 2015 at 12:51 PM, Dmitriy Shulyak <<a href="mailto:dshulyak@mirantis.com">dshulyak@mirantis.com</a>> wrote:<br>
> Hi,<br>
><br>
>> Can we ignore the problem above and remove this limitation? Or should<br>
>> we improve it somehow so it would work for one nodes, and will be<br>
>> ignored for others?<br>
><br>
> I think that this validation needs to be accomplished in a different way, we<br>
> don't need 1 controller for the sake of 1 controller,<br>
> 1 controller is a dependency of compute/cinder/other roles. So from my pov<br>
> there is atleast 2 options:<br>
><br>
> 1. Use tasks dependencies, and prevent deployment in case if some tasks<br>
> relies on controller.<br>
> But the implementation might be complicated<br>
><br>
> 2. Insert required metadata into roles that relies on another roles, for<br>
> compute it will be something like:<br>
>    compute:<br>
>      requires: controller > 1<br>
> We actually have DSL for declaring such things, we just need to specify this<br>
> requirements from other side.<br>
><br>
> But in 2nd case we will still need to use tricks, like one provided by Matt,<br>
> for certain plugins. So maybe we should spend time and do 1st.<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 12<br>
Date: Wed, 21 Oct 2015 13:15:03 +0300<br>
From: Dmitriy Shulyak <<a href="mailto:dshulyak@mirantis.com">dshulyak@mirantis.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Fuel][Plugins] Plugin deployment<br>
        questions<br>
Message-ID:<br>
        <<a href="mailto:CAP2-cGdcgeFC2vJJ6otck15_-eRRs5cMHwfpyZ0ojRW7aOizqA@mail.gmail.com">CAP2-cGdcgeFC2vJJ6otck15_-eRRs5cMHwfpyZ0ojRW7aOizqA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
But it will lead to situations, when certain plugins, like<br>
standalone_rabbitmq/standalone_mysql will need to overwrite settings on<br>
*all*<br>
dependent roles, and it might be a problem.. Because, how plugin developer<br>
will be able to know what are those roles?<br>
<br>
On Wed, Oct 21, 2015 at 1:01 PM, Igor Kalnitsky <<a href="mailto:ikalnitsky@mirantis.com">ikalnitsky@mirantis.com</a>><br>
wrote:<br>
<br>
> Hi Dmitry,<br>
><br>
> > Insert required metadata into roles that relies on another roles, for<br>
> > compute it will be something like:<br>
> ><br>
> >     compute:<br>
> >         requires: controller > 1<br>
><br>
> Yeah, that's actually what I was thinking about when I wrote:<br>
><br>
> > Or should we improve it somehow so it would work for one nodes,<br>
> > and will be ignored for others?<br>
><br>
> So I'm +1 for extending our meta information with such dependencies.<br>
><br>
> Sincerely,<br>
> Igor<br>
><br>
> On Wed, Oct 21, 2015 at 12:51 PM, Dmitriy Shulyak <<a href="mailto:dshulyak@mirantis.com">dshulyak@mirantis.com</a>><br>
> wrote:<br>
> > Hi,<br>
> ><br>
> >> Can we ignore the problem above and remove this limitation? Or should<br>
> >> we improve it somehow so it would work for one nodes, and will be<br>
> >> ignored for others?<br>
> ><br>
> > I think that this validation needs to be accomplished in a different<br>
> way, we<br>
> > don't need 1 controller for the sake of 1 controller,<br>
> > 1 controller is a dependency of compute/cinder/other roles. So from my<br>
> pov<br>
> > there is atleast 2 options:<br>
> ><br>
> > 1. Use tasks dependencies, and prevent deployment in case if some tasks<br>
> > relies on controller.<br>
> > But the implementation might be complicated<br>
> ><br>
> > 2. Insert required metadata into roles that relies on another roles, for<br>
> > compute it will be something like:<br>
> >    compute:<br>
> >      requires: controller > 1<br>
> > We actually have DSL for declaring such things, we just need to specify<br>
> this<br>
> > requirements from other side.<br>
> ><br>
> > But in 2nd case we will still need to use tricks, like one provided by<br>
> Matt,<br>
> > for certain plugins. So maybe we should spend time and do 1st.<br>
> ><br>
> ><br>
> __________________________________________________________________________<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20151021/d5a0a15f/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20151021/d5a0a15f/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 13<br>
Date: Wed, 21 Oct 2015 13:21:33 +0300<br>
From: Igor Kalnitsky <<a href="mailto:ikalnitsky@mirantis.com">ikalnitsky@mirantis.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Fuel][Plugins] Plugin deployment<br>
        questions<br>
Message-ID:<br>
        <CACo6NWDaRHO=<a href="mailto:itGZvnKFZDN0z5q-CZQXL_WkdczNgUyJ--U2ew@mail.gmail.com">itGZvnKFZDN0z5q-CZQXL_WkdczNgUyJ--U2ew@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
We can make bidirectional dependencies, just like our deployment tasks do.<br>
<br>
And, btw, standalone-* roles may have a restriction that at least one<br>
node is required. I think it's ok for the plugin is case, since if you<br>
don't want to use it - just disable it.<br>
<br>
On Wed, Oct 21, 2015 at 1:15 PM, Dmitriy Shulyak <<a href="mailto:dshulyak@mirantis.com">dshulyak@mirantis.com</a>> wrote:<br>
> But it will lead to situations, when certain plugins, like<br>
> standalone_rabbitmq/standalone_mysql will need to overwrite settings on<br>
> *all*<br>
> dependent roles, and it might be a problem.. Because, how plugin developer<br>
> will be able to know what are those roles?<br>
><br>
> On Wed, Oct 21, 2015 at 1:01 PM, Igor Kalnitsky <<a href="mailto:ikalnitsky@mirantis.com">ikalnitsky@mirantis.com</a>><br>
> wrote:<br>
>><br>
>> Hi Dmitry,<br>
>><br>
>> > Insert required metadata into roles that relies on another roles, for<br>
>> > compute it will be something like:<br>
>> ><br>
>> >     compute:<br>
>> >         requires: controller > 1<br>
>><br>
>> Yeah, that's actually what I was thinking about when I wrote:<br>
>><br>
>> > Or should we improve it somehow so it would work for one nodes,<br>
>> > and will be ignored for others?<br>
>><br>
>> So I'm +1 for extending our meta information with such dependencies.<br>
>><br>
>> Sincerely,<br>
>> Igor<br>
>><br>
>> On Wed, Oct 21, 2015 at 12:51 PM, Dmitriy Shulyak <<a href="mailto:dshulyak@mirantis.com">dshulyak@mirantis.com</a>><br>
>> wrote:<br>
>> > Hi,<br>
>> ><br>
>> >> Can we ignore the problem above and remove this limitation? Or should<br>
>> >> we improve it somehow so it would work for one nodes, and will be<br>
>> >> ignored for others?<br>
>> ><br>
>> > I think that this validation needs to be accomplished in a different<br>
>> > way, we<br>
>> > don't need 1 controller for the sake of 1 controller,<br>
>> > 1 controller is a dependency of compute/cinder/other roles. So from my<br>
>> > pov<br>
>> > there is atleast 2 options:<br>
>> ><br>
>> > 1. Use tasks dependencies, and prevent deployment in case if some tasks<br>
>> > relies on controller.<br>
>> > But the implementation might be complicated<br>
>> ><br>
>> > 2. Insert required metadata into roles that relies on another roles, for<br>
>> > compute it will be something like:<br>
>> >    compute:<br>
>> >      requires: controller > 1<br>
>> > We actually have DSL for declaring such things, we just need to specify<br>
>> > this<br>
>> > requirements from other side.<br>
>> ><br>
>> > But in 2nd case we will still need to use tricks, like one provided by<br>
>> > Matt,<br>
>> > for certain plugins. So maybe we should spend time and do 1st.<br>
>> ><br>
>> ><br>
>> > __________________________________________________________________________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
>> > <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> ><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 14<br>
Date: Wed, 21 Oct 2015 10:28:19 +0000<br>
From: Paul Michali <<a href="mailto:pc@michali.net">pc@michali.net</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Neutron] HenryG addition to the Neutron<br>
        Drivers team<br>
Message-ID:<br>
        <CA+ikoROSS7=<a href="mailto:xOqBLzHoOAVXd%2Beze8ZFk7Fcf7EkLboJEUQ8ZFA@mail.gmail.com">xOqBLzHoOAVXd+eze8ZFk7Fcf7EkLboJEUQ8ZFA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Congratulations Henry!<br>
<br>
<br>
On Wed, Oct 21, 2015 at 5:03 AM Ihar Hrachyshka <<a href="mailto:ihrachys@redhat.com">ihrachys@redhat.com</a>> wrote:<br>
<br>
><br>
> > On 21 Oct 2015, at 05:14, Armando M. <<a href="mailto:armamig@gmail.com">armamig@gmail.com</a>> wrote:<br>
> ><br>
> > Hi folks,<br>
> ><br>
> > Henry has been instrumental in many areas of the projects and his crazy<br>
> working hours makes even Kevin and I bow in awe.<br>
> ><br>
> > Jokes aside, I would like to announce HenryG as a new member of the<br>
> Neutron Drivers team.<br>
> ><br>
> > Having a propension to attendance, and desire to review of RFEs puts you<br>
> on the right foot to join the group, whose members are rotated regularly so<br>
> that everyone is given the opportunity to grow, and no-one burns out.<br>
> ><br>
> > The team [1] meets regularly on Tuesdays [2], and anyone is welcome to<br>
> attend.<br>
> ><br>
> > Please, join me in welcome Henry to the team.<br>
><br>
> Nice addition. :)<br>
><br>
> Do we have criteria for neutron-drivers team members documented? Or is it<br>
> a mere ?regularly attending the meetings, be mindful and apply common<br>
> sense??<br>
><br>
> Ihar<br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20151021/02bf5ad8/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20151021/02bf5ad8/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 15<br>
Date: Wed, 21 Oct 2015 11:34:43 +0100<br>
From: Adam Spiers <<a href="mailto:aspiers@suse.com">aspiers@suse.com</a>><br>
To: openstack-dev mailing list <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>,<br>
        Pacemaker users list <<a href="mailto:users@clusterlabs.org">users@clusterlabs.org</a>><br>
Subject: [openstack-dev] [ANNOUNCE] [HA] [Pacemaker] new, maintained<br>
        openstack-resource-agents repository<br>
Message-ID: <20151021103443.GM11893@pacific.linksys.moosehall><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
[cross-posting to openstack-dev and pacemaker user lists; please<br>
consider trimming the recipients list if your reply is not relevant to<br>
both communities]<br>
<br>
Hi all,<br>
<br>
Back in June I proposed moving the well-used but no longer maintained<br>
<a href="https://github.com/madkiss/openstack-resource-agents/" rel="noreferrer" target="_blank">https://github.com/madkiss/openstack-resource-agents/</a> repository to<br>
Stackforge:<br>
<br>
  <a href="http://lists.openstack.org/pipermail/openstack-dev/2015-June/067763.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2015-June/067763.html</a><br>
  <a href="https://github.com/madkiss/openstack-resource-agents/issues/22" rel="noreferrer" target="_blank">https://github.com/madkiss/openstack-resource-agents/issues/22</a><br>
<br>
The responses I got were more or less unanimously in favour, so I'm<br>
simultaneously pleased and slightly embarrassed to announce that 4<br>
months later, I've finally followed up on my proposal:<br>
<br>
  <a href="https://launchpad.net/openstack-resource-agents" rel="noreferrer" target="_blank">https://launchpad.net/openstack-resource-agents</a><br>
  <a href="https://git.openstack.org/cgit/openstack/openstack-resource-agents/" rel="noreferrer" target="_blank">https://git.openstack.org/cgit/openstack/openstack-resource-agents/</a><br>
  <a href="https://review.openstack.org/#/admin/projects/openstack/openstack-resource-agents" rel="noreferrer" target="_blank">https://review.openstack.org/#/admin/projects/openstack/openstack-resource-agents</a><br>
  <a href="https://review.openstack.org/#/q/status:open+project:openstack/openstack-resource-agents,n,z" rel="noreferrer" target="_blank">https://review.openstack.org/#/q/status:open+project:openstack/openstack-resource-agents,n,z</a><br>
<br>
Since June, Stackforge has been retired, so as you can see above, this<br>
repository lives under the 'openstack' namespace.<br>
<br>
I volunteered to be a maintainer and there were no objections.  I sent<br>
out an initial call for co-maintainers but noone expressed an interest<br>
which is probably fine because the workload is likely to be quite<br>
light.  However if you'd like to be involved please drop me a line.<br>
<br>
I've also taken care of outstanding pull requests and bug reports<br>
against the old repository, and providing a redirect from the old<br>
repository's README to the new one.<br>
<br>
Still TODO: adding this repository to the Big Tent.  I've had some<br>
discussions with the openstack-infra team about that, since there is<br>
not currently a suitable project team to create it under.  We might<br>
create a new project team called "OpenStack Pacemaker" or similar, and<br>
place it under that.  ("OpenStack HA" would be far too broad to be<br>
able to find a single PTL.)  However there is no rush for this, and it<br>
has been suggested that it would not be a bad thing to wait for the<br>
"new" project to stabilise and prove its longevity before making it<br>
official.<br>
<br>
Cheers,<br>
Adam<br>
<br>
P.S. I'll be in Tokyo if anyone wants to meet there and discuss<br>
further.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 16<br>
Date: Wed, 21 Oct 2015 11:36:00 +0100<br>
From: John Spray <<a href="mailto:jspray@redhat.com">jspray@redhat.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [Manila] Share allow/deny by shared secret<br>
Message-ID:<br>
        <CALe9h7cEv=jb1xqskK9vnTZ9C8V_XS+-ZHgFuhuU0ru=<a href="mailto:9aOM3g@mail.gmail.com">9aOM3g@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Hi,<br>
<br>
(I wanted to put this in an email ahead of Tokyo, where I hope we'll<br>
find time to discuss it.  This is a follow up to<br>
<a href="http://osdir.com/ml/openstack-dev/2015-10/msg00381.html" rel="noreferrer" target="_blank">http://osdir.com/ml/openstack-dev/2015-10/msg00381.html</a>)<br>
<br>
With the current code, there doesn't appear to be a proper way to<br>
expose Ceph's native authentication system via Manila.  This is<br>
because Ceph generates the shared secret needed to access a share, and<br>
Manila doesn't give us a path to expose such a driver-originated<br>
secret as part of a ShareInstanceMapping.<br>
<br>
The NFS-style process that Manila expects is:<br>
Caller> I know a credential (IP address, x509 certificate) and I want<br>
you to authorize it<br>
Driver> OK, I have stored that credential and you can now use it to<br>
access the share.<br>
<br>
The Ceph native process is more like:<br>
Caller> I want to access this share<br>
Driver> OK, I have generated a credential for you, here it is, you can<br>
now use it to access the share<br>
<br>
The important distinction is where the credential comes from.  Manila<br>
expects it to come from the caller, Ceph expects to generate it for<br>
the caller.<br>
<br>
To enable us to expose ceph native auth, I propose:<br>
 * Add a "key" column to the ShareAccessMapping model<br>
 * Enable drivers to optionally populate this from allow() methods<br>
 * Expose this to API consumers: right to see a share mapping is the<br>
right to see the key.<br>
<br>
The security model is that the key is a secret, which Manila API users<br>
(i.e. administrative functions) are allowed to see, and it is up to<br>
them to selectively share the secret with guests.  The reason for<br>
giving them allow/deny rather than just having a key per share is so<br>
that the administrator can selectively revoke keys.<br>
<br>
The "key" column should be pretty short (255 chars is plenty) -- this<br>
isn't meant for storing big things like PKI certificates, it's<br>
specifically for shared secrets.<br>
<br>
I don't know of any other drivers that would use this, but it is a<br>
pretty generic concept in itself: "grant access by a shared key that<br>
the storage system generates".<br>
<br>
Cheers,<br>
John<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 17<br>
Date: Wed, 21 Oct 2015 10:43:01 +0000<br>
From: "Murray, Paul (HP Cloud)" <<a href="mailto:pmurray@hpe.com">pmurray@hpe.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] Custom Nova scheduler based on CPU queue<br>
        length<br>
Message-ID:<br>
        <<a href="mailto:39E5672E03A1CB4B93936D1C4AA5E15D1DC318E2@G1W3782.americas.hpqcorp.net">39E5672E03A1CB4B93936D1C4AA5E15D1DC318E2@G1W3782.americas.hpqcorp.net</a>><br>
<br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi Rahul,<br>
<br>
> As I understand a weigher for the filter scheduler that weighs filtered host machines based on the host weight option, 'cpu.percent' can be<br>
> configured to prioritize the hosts based on CPU percentage, but there are only limited options when it comes to filtering of machines in the<br>
> first place, that too using the CPU queue length.<br>
><br>
> Also, I understand that IBM has its platform resource scheduler that can be used to build custom plugins to get user defined metrics, is there<br>
> a similar way in pure Openstack which can be used to get the CPU queue length.<br>
><br>
> As of now, I am thinking of writing a custom script to be kept in all compute nodes to retrieve the CPU queue length and send it to the Nova<br>
> controller, is this the way to go, or is there a defined approach that I can follow to implement a scheduler that uses CPU queue length to filter<br>
> physical machines.<br>
<br>
Nova has metric plugins (monitors) in the resource tracker at the compute manager that will report metric data like this to the scheduler.<br>
Any weigher plugins can use that data.<br>
<br>
To see how cpu.percentage is set and used see the following plugins:<br>
nova/compute/monitors/cpu_monitor.py<br>
nova/scheduler/weights/metrics.py<br>
<br>
You can create new monitor and weigher plugins using these as a model or propose an addition to cpu_monitor.py if you think it is generally useful.<br>
<br>
Paul<br>
<br>
------------------------------<br>
<br>
Message: 18<br>
Date: Wed, 21 Oct 2015 12:45:28 +0200<br>
From: Patrick Petit <<a href="mailto:ppetit@mirantis.com">ppetit@mirantis.com</a>><br>
To: Igor Kalnitsky <<a href="mailto:ikalnitsky@mirantis.com">ikalnitsky@mirantis.com</a>>,  "OpenStack Development<br>
        Mailing List (not for usage questions)"<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Fuel][Plugins] Plugin deployment<br>
        questions<br>
Message-ID: <etPan.56276cc8.28d2402d.102c@Rangiroa.local><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On 21 Oct 2015 at 12:21:57, Igor Kalnitsky (<a href="mailto:ikalnitsky@mirantis.com">ikalnitsky@mirantis.com</a>) wrote:<br>
We can make bidirectional dependencies, just like our deployment tasks do.<br>
<br>
<br>
Just to make sure we are on the same page?<br>
We don?t want to be in a situation where a role needs to know about the its reverse dependencies.<br>
Dependencies are always expressed one direction. Right?<br>
<br>
And, btw, standalone-* roles may have a restriction that at least one<br>
node is required. I think it's ok for the plugin is case, since if you<br>
don't want to use it - just disable it.<br>
<br>
On Wed, Oct 21, 2015 at 1:15 PM, Dmitriy Shulyak <<a href="mailto:dshulyak@mirantis.com">dshulyak@mirantis.com</a>> wrote:<br>
> But it will lead to situations, when certain plugins, like<br>
> standalone_rabbitmq/standalone_mysql will need to overwrite settings on<br>
> *all*<br>
> dependent roles, and it might be a problem.. Because, how plugin developer<br>
> will be able to know what are those roles?<br>
><br>
> On Wed, Oct 21, 2015 at 1:01 PM, Igor Kalnitsky <<a href="mailto:ikalnitsky@mirantis.com">ikalnitsky@mirantis.com</a>><br>
> wrote:<br>
>><br>
>> Hi Dmitry,<br>
>><br>
>> > Insert required metadata into roles that relies on another roles, for<br>
>> > compute it will be something like:<br>
>> ><br>
>> > compute:<br>
>> > requires: controller > 1<br>
>><br>
>> Yeah, that's actually what I was thinking about when I wrote:<br>
>><br>
>> > Or should we improve it somehow so it would work for one nodes,<br>
>> > and will be ignored for others?<br>
>><br>
>> So I'm +1 for extending our meta information with such dependencies.<br>
>><br>
>> Sincerely,<br>
>> Igor<br>
>><br>
>> On Wed, Oct 21, 2015 at 12:51 PM, Dmitriy Shulyak <<a href="mailto:dshulyak@mirantis.com">dshulyak@mirantis.com</a>><br>
>> wrote:<br>
>> > Hi,<br>
>> ><br>
>> >> Can we ignore the problem above and remove this limitation? Or should<br>
>> >> we improve it somehow so it would work for one nodes, and will be<br>
>> >> ignored for others?<br>
>> ><br>
>> > I think that this validation needs to be accomplished in a different<br>
>> > way, we<br>
>> > don't need 1 controller for the sake of 1 controller,<br>
>> > 1 controller is a dependency of compute/cinder/other roles. So from my<br>
>> > pov<br>
>> > there is atleast 2 options:<br>
>> ><br>
>> > 1. Use tasks dependencies, and prevent deployment in case if some tasks<br>
>> > relies on controller.<br>
>> > But the implementation might be complicated<br>
>> ><br>
>> > 2. Insert required metadata into roles that relies on another roles, for<br>
>> > compute it will be something like:<br>
>> > compute:<br>
>> > requires: controller > 1<br>
>> > We actually have DSL for declaring such things, we just need to specify<br>
>> > this<br>
>> > requirements from other side.<br>
>> ><br>
>> > But in 2nd case we will still need to use tricks, like one provided by<br>
>> > Matt,<br>
>> > for certain plugins. So maybe we should spend time and do 1st.<br>
>> ><br>
>> ><br>
>> > __________________________________________________________________________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
>> > <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> ><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20151021/67d7b30e/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20151021/67d7b30e/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 19<br>
Date: Wed, 21 Oct 2015 14:12:59 +0300<br>
From: Gal Sagie <<a href="mailto:gal.sagie@gmail.com">gal.sagie@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>,  Antoni Segura Puimedon<br>
        <<a href="mailto:toni@midokura.com">toni@midokura.com</a>>, Irena Berezovsky <<a href="mailto:irena@midokura.com">irena@midokura.com</a>>,  Mohammad<br>
        Banikazemi <<a href="mailto:mb@us.ibm.com">mb@us.ibm.com</a>>, Taku Fukushima <<a href="mailto:tfukushima@midokura.com">tfukushima@midokura.com</a>>,<br>
        Eran Gampel <<a href="mailto:Eran.Gampel@huawei.com">Eran.Gampel@huawei.com</a>><br>
Subject: Re: [openstack-dev] [Neutron] Gerrit permissions and Merge<br>
        rights<br>
Message-ID:<br>
        <CAG9LJa762NVQeCo__=+mqyPojxLHHdhY7nPRKTLvkDP5hGE9=<a href="mailto:g@mail.gmail.com">g@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Do we also want to consider Project Kuryr part of this?<br>
We already started sending Kuryr spec to the Neutron repository and I think<br>
it would make sense to manage it<br>
as part of Neutron spec process.<br>
<br>
Any opinions on that?<br>
<br>
Gal.<br>
<br>
On Tue, Oct 20, 2015 at 11:10 PM, Armando M. <<a href="mailto:armamig@gmail.com">armamig@gmail.com</a>> wrote:<br>
<br>
> Hi folks,<br>
><br>
> During revision of the Neutron teams [1], we made clear that the<br>
> neutron-specs repo is to be targeted by specs for all the Neutron projects<br>
> (core + *-aas).<br>
><br>
> For this reason I made sure that the neutron-specs-core team +2 right was<br>
> extended to all the core teams.<br>
><br>
> Be mindful, use your +2 rights with care: if you are core on a *-aas<br>
> project, you should exercise that vote only for specs that pertain the<br>
> project you're core of.<br>
><br>
> If I could use this email as a reminder also of the core hierarchy and<br>
> lieutenant system we switched to in Liberty ([3]): if you have been made<br>
> core by a lieutenant of a sub-system, please use your +2/+A only within<br>
> your area of comfort and reach out for help if in doubt.<br>
><br>
> Reviews are always welcome though!<br>
><br>
> Cheers,<br>
> Armando<br>
><br>
> [1] <a href="https://review.openstack.org/#/c/237180/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/237180/</a><br>
> [2] <a href="https://review.openstack.org/#/admin/groups/314,members" rel="noreferrer" target="_blank">https://review.openstack.org/#/admin/groups/314,members</a><br>
> [3]<br>
> <a href="http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#core-review-hierarchy" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#core-review-hierarchy</a><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
<br>
<br>
--<br>
Best Regards ,<br>
<br>
The G.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20151021/1eaf3ebd/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20151021/1eaf3ebd/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 20<br>
Date: Wed, 21 Oct 2015 13:17:44 +0200<br>
From: Dmitry Tantsur <<a href="mailto:dtantsur@redhat.com">dtantsur@redhat.com</a>><br>
To: <a href="mailto:openstack-announce@lists.openstack.org">openstack-announce@lists.openstack.org</a>, "OpenStack Development<br>
        Mailing List (not for usage questions)"<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [release][stable][ironic] ironic-inspector<br>
        release 2.2.2 (liberty)<br>
Message-ID: <<a href="mailto:56277458.2030504@redhat.com">56277458.2030504@redhat.com</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
We are gleeful to announce the release of:<br>
<br>
ironic-inspector 2.2.2: Hardware introspection for OpenStack Bare Metal<br>
<br>
With source available at:<br>
<br>
     <a href="http://git.openstack.org/cgit/openstack/ironic-inspector" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/openstack/ironic-inspector</a><br>
<br>
The most important change is a fix for CVE-2015-5306, all users<br>
(including users of ironic-discoverd) are highly advised to update.<br>
<br>
Another user-visible change is defaulting MySQL to InnoDB, as MyISAM is<br>
known not to work.<br>
<br>
For more details, please see the git log history below and:<br>
<br>
     <a href="http://launchpad.net/ironic-inspector/+milestone/2.2.2" rel="noreferrer" target="_blank">http://launchpad.net/ironic-inspector/+milestone/2.2.2</a><br>
<br>
Please report issues through launchpad:<br>
<br>
     <a href="http://bugs.launchpad.net/ironic-inspector" rel="noreferrer" target="_blank">http://bugs.launchpad.net/ironic-inspector</a><br>
<br>
Changes in ironic-inspector 2.2.1..2.2.2<br>
----------------------------------------<br>
<br>
95db43c Always default to InnoDB for MySQL<br>
2d42cdf Updated from global requirements<br>
2c64da2 Never run Flask application with debug mode<br>
bbf31de Fix gate broken by the devstack trueorfalse change<br>
12eaf81 Use auth_strategy=noauth in functional tests<br>
<br>
Diffstat (except docs and test files)<br>
-------------------------------------<br>
<br>
devstack/plugin.sh                                 |  2 +-<br>
ironic_inspector/db.py                             |  7 ++-<br>
ironic_inspector/main.py                           |  5 +--<br>
.../versions/578f84f38d_inital_db_schema.py        | 12 +++--<br>
.../migrations/versions/d588418040d_add_rules.py   | 10 ++++-<br>
ironic_inspector/test/functional.py                | 51<br>
+++++++++++-----------<br>
requirements.txt                                   |  2 +-<br>
7 files changed, 52 insertions(+), 37 deletions(-)<br>
<br>
<br>
Requirements updates<br>
--------------------<br>
<br>
diff --git a/requirements.txt b/requirements.txt<br>
index e53d673..39b8423 100644<br>
--- a/requirements.txt<br>
+++ b/requirements.txt<br>
@@ -21 +21 @@ oslo.rootwrap>=2.0.0 # Apache-2.0<br>
-oslo.utils>=2.0.0 # Apache-2.0<br>
+oslo.utils!=2.6.0,>=2.0.0 # Apache-2.0<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 21<br>
Date: Wed, 21 Oct 2015 11:26:54 +0000<br>
From: "Dave McCowan (dmccowan)" <<a href="mailto:dmccowan@cisco.com">dmccowan@cisco.com</a>><br>
To: "<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>"<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev]<br>
        openstack-barbican-authenticate-keystone-barbican-command<br>
Message-ID: <<a href="mailto:D24CEDD5.1FA05%25dmccowan@cisco.com">D24CEDD5.1FA05%dmccowan@cisco.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Hi Arif--<br>
    Are you using Keystone for authentication?<br>
    If so, you need to get an authentication token from Keystone and add it as a header to your curl command: -H "X-Auth-Token:$TOKEN".<br>
    You do not need to specify the project ID (-H 'X-Project-Id:12345').  The project ID will be based on your Keystone user's project ID.<br>
--Dave<br>
<br>
From: OpenStack Mailing List Archive <<a href="mailto:corpqa@gmail.com">corpqa@gmail.com</a><mailto:<a href="mailto:corpqa@gmail.com">corpqa@gmail.com</a>>><br>
Reply-To: "<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>><br>
Date: Wednesday, October 21, 2015 at 3:11 AM<br>
To: "<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>><br>
Subject: [openstack-dev] openstack-barbican-authenticate-keystone-barbican-command<br>
<br>
Link: <a href="https://openstack.nimeyo.com/62868/?show=62868#q62868" rel="noreferrer" target="_blank">https://openstack.nimeyo.com/62868/?show=62868#q62868</a><br>
From: marif82 <<a href="mailto:marif82@gmail.com">marif82@gmail.com</a><mailto:<a href="mailto:marif82@gmail.com">marif82@gmail.com</a>>><br>
<br>
<br>
Hi Asha,<br>
<br>
I am also getting the same error when I am executing the curl command to create secret.<br>
<br>
bash-4.2$ curl -X POST -H 'content-type:application/json' -H 'X-Project-Id:12345' -d '{"payload": "my-secret-here","payloadcontenttype": "text/plain"}' <a href="http://localhost:9311/v1/secrets" rel="noreferrer" target="_blank">http://localhost:9311/v1/secrets</a><br>
Authentication requiredbash-4.2$<br>
<br>
Can you please help me how you have solved this problem. I am using the safenet HSM for MKEK and HMAC and it generated successfully on HSM partition.<br>
<br>
Please help me to resolve this issue.<br>
<br>
Thanks & Regards,<br>
Arif<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20151021/0784a1ed/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20151021/0784a1ed/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 22<br>
Date: Wed, 21 Oct 2015 11:34:14 +0000<br>
From: "Qiao, Liyong" <<a href="mailto:liyong.qiao@intel.com">liyong.qiao@intel.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [magnum] k8s api tls_enabled mode testing<br>
Message-ID:<br>
        <<a href="mailto:4AAC01E2A34C48429D201A50CC57A8153A00244B@SHSMSX101.ccr.corp.intel.com">4AAC01E2A34C48429D201A50CC57A8153A00244B@SHSMSX101.ccr.corp.intel.com</a>><br>
<br>
Content-Type: text/plain; charset="gb2312"<br>
<br>
Hello,<br>
I need your help on k8s api tls_enabled mode.<br>
Here?s my patch <a href="https://review.openstack.org/232421" rel="noreferrer" target="_blank">https://review.openstack.org/232421</a><br>
<br>
It is always failed on gate, but it works in my setup.<br>
Debug more I found that the ca cert return api return length with difference:<br>
<br>
On my setup?<br>
10.238.157.49 - - [21/Oct/2015 19:16:17] "POST /v1/certificates HTTP/1.1" 201 3360<br>
?<br>
10.238.157.49 - - [21/Oct/2015 19:16:17] "GET /v1/certificates/d4bf6135-a3d0-4980-a785-e3f2900ca315 HTTP/1.1" 200 1357<br>
<br>
On gate:<br>
<br>
127.0.0.1 - - [21/Oct/2015 10:59:40] "POST /v1/certificates HTTP/1.1" 201 3352<br>
<br>
127.0.0.1 - - [21/Oct/2015 10:59:40] "GET /v1/certificates/a9aa1bbd-d624-4791-a4b9-e7a076c8bf58 HTTP/1.1" 200 1349<br>
<br>
<br>
<br>
Misses 8 Bit.<br>
<br>
<br>
<br>
I also print out the cert file content, but the length of both on gate and my setup are same.<br>
<br>
But failed on gate due to SSL exception.<br>
<br>
Does anyone know what will be the root cause?<br>
<br>
<br>
<br>
<br>
BR, Eli(Li Yong)Qiao<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20151021/00ca027b/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20151021/00ca027b/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 23<br>
Date: Wed, 21 Oct 2015 14:42:59 +0300<br>
From: Dmitriy Shulyak <<a href="mailto:dshulyak@mirantis.com">dshulyak@mirantis.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Fuel][Plugins] Plugin deployment<br>
        questions<br>
Message-ID:<br>
        <<a href="mailto:CAP2-cGeNwtK7x4r2S7OvpsukZe77d3jGKX6JpW_gm-1hCzL0yQ@mail.gmail.com">CAP2-cGeNwtK7x4r2S7OvpsukZe77d3jGKX6JpW_gm-1hCzL0yQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On Wed, Oct 21, 2015 at 1:21 PM, Igor Kalnitsky <<a href="mailto:ikalnitsky@mirantis.com">ikalnitsky@mirantis.com</a>><br>
wrote:<br>
<br>
> We can make bidirectional dependencies, just like our deployment tasks do.<br>
<br>
<br>
I'm not sure that we are on the same page regarding problem definition.<br>
Imagine the case when we have environment with next set of roles:<br>
<br>
1. standalone-rabbitmq<br>
2. standalone-mysql<br>
3. standalone-other-api things<br>
4. compute - requires: controller > 1<br>
5. cinder - requires: controller > 1<br>
6. designate (whatever custom role) - requires: controller > 1<br>
<br>
As you see - there is no controller anymore.<br>
And 1, 2, 3 developed by one guy, who knows that he need to overwrite<br>
requirements for 4,5, but he knows nothing about 6.<br>
At the same time developer of 6 role, obviously, knows nothing about<br>
standalone-* things.<br>
What options do we have here?<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20151021/f334d812/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20151021/f334d812/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 24<br>
Date: Wed, 21 Oct 2015 14:46:42 +0300<br>
From: Vladimir Kozhukalov <<a href="mailto:vkozhukalov@mirantis.com">vkozhukalov@mirantis.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev]  [Fuel] shotgun code freeze<br>
Message-ID:<br>
        <CAFLqvG7NtVMja29fddpKO3=<a href="mailto:XAyMsTqXhs_qOb%2B9A_3EAtkJ6ag@mail.gmail.com">XAyMsTqXhs_qOb+9A_3EAtkJ6ag@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Dear colleagues,<br>
<br>
As you might know I'm working on splitting multiproject fuel-web repository<br>
into several sub-projects. Shotgun is one of directories that are to be<br>
moved to a separate git project.<br>
<br>
Checklist for this to happen is as follows:<br>
<br>
   - Launchpad bug <a href="https://bugs.launchpad.net/fuel/+bug/1506894" rel="noreferrer" target="_blank">https://bugs.launchpad.net/fuel/+bug/1506894</a><br>
   - project-config patch  <a href="https://review.openstack.org/#/c/235355" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/235355</a> (ON<br>
   REVIEW)<br>
   - pypi project<br>
   <a href="https://pypi.python.org/pypi?%3Aaction=pkg_edit&name=Shotgun" rel="noreferrer" target="_blank">https://pypi.python.org/pypi?%3Aaction=pkg_edit&name=Shotgun</a> (DONE)<br>
   - run_tests.sh  <a href="https://review.openstack.org/235368" rel="noreferrer" target="_blank">https://review.openstack.org/235368</a> (DONE)<br>
   - rpm/deb specs  <a href="https://review.openstack.org/#/c/235382" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/235382</a> (DONE)<br>
   - fuel-ci verification jobs <a href="https://review.fuel-infra.org/#/c/12872/" rel="noreferrer" target="_blank">https://review.fuel-infra.org/#/c/12872/</a> (ON<br>
   REVIEW)<br>
   - label jenkins slaves for verification jobs (ci team)<br>
   - directory freeze (WE ARE HERE)<br>
   - prepare upstream (TODO)<br>
   - waiting for project-config patch to be merged (ON REVIEW)<br>
   - fuel-main patch (TODO)<br>
   - packaging-ci patch (TODO)<br>
   - deprecate fuel-web/shotgun directory (TODO)<br>
<br>
Now we are at the point where we need to freeze fuel-web/shotgun directory.<br>
So, I'd like to announce code freeze for this directory and all patches<br>
that make changes in the directory and are currently on review will need to<br>
be backported to the new git repository.<br>
<br>
Vladimir Kozhukalov<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20151021/59aff5d8/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20151021/59aff5d8/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
End of OpenStack-dev Digest, Vol 42, Issue 58<br>
*********************************************<br>
</blockquote></div><br></div></div>