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