[openstack-dev] [qinling] Qinling dashboard demo

[Lingxian Kong]

Hi all,

Thanks to the effort from Keiichi Hikita of qinling-dashboard team, we have
an initial version of qinling-dashboard available(but unfortunately it's
not included in Rocky). Keiichi Hikita also recorded a video for the
introduction, you can see the demo here[1]. The team will continue to add
more features that Qinling provides and improve the panels to make the
function developers happy.

Any feedback or suggestion is welcomed.

[1]: https://youtu.be/fdySaFZb2cY

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

Re: [openstack-dev] [mistral] Removing Inactive Cores

[Lingxian Kong]

+1 for me, i am still watching mistral :-)

Cheers,
Lingxian Kong


On Fri, Aug 3, 2018 at 9:58 PM Dougal Matthews  wrote:

> Hey,
>
> As we are approaching the end of Rocky I am doing some house keeping.
>
> The people below have been removed from the Mistral core team due to
> reviewing inactivity in the last 180 days[1]. I would like to thank them
> for their contributions and they are welcome to re-join the Mistral core
> team if they become active in the future.
>
> - Lingxian Kong
> - Winson Chan
>
> [1] http://stackalytics.com/report/contribution/mistral-group/180
>
> Thanks,
> Dougal
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [qinling] [PTL] [Election] PTL candidacy for the Stein cycle

[Lingxian Kong]

Hi all,

I'm writing this email to propose myself as Qinling PTL for Stein dev cycle.

I have been serving as Qinling PTL in Rocky, the first dev cycle for
Qinling as
an official OpenStack project. Qinling is a small team for now but we did
have
made significant improvements and enhancements during Rocky, e.g. support
TLS
communication with k8s API server, support untrusted runtime so that Qinling
can leverage the security container technology such as Kata container and
gVisor to run untrusted functions, we also add function alias support to
make
it easy to invoke the function for the function consumers. Additionally,
Qinling documentation also has improved a little bit thanks to all the
contributors.

Although there are a bunch of competitors to Qinling in serverless area
especially in k8s ecosystem, the main difference between Qinling and other
solutions is OpenStack is always the first citizen in Qinling's world,
support
the integration with other OpenStack services is always our first priority.
So
we won't compete with other FaaS projects and we don't care.

So speaking of Stein, I'd like to take some time to focus on the next set of
challenges to make Qinling production ready as soon as possible(it's also an
internal goal in my own team):

- Continue to work on the runtime security issue
- High availability of qinling-api and qinling-engine
- More intelligent execution scale algorithm

Besides, all other contributions to Qinling are welcomed.

Thank you all for taking a moment to read what I have to say.

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

Re: [openstack-dev] [magnum] Nominate Feilong Wang for Core Reviewer

[Lingxian Kong]

Huge +1


Cheers,
Lingxian Kong

On Tue, Jul 17, 2018 at 7:04 PM, Yatin Karel  wrote:

> +2 Well deserved.
>
> Welcome Feilong and Thanks for all the Great Work!!!
>
>
> Regards
> Yatin Karel
>
> On Tue, Jul 17, 2018 at 12:27 PM, Spyros Trigazis 
> wrote:
> > Hello list,
> >
> > I'm excited to nominate Feilong as Core Reviewer for the Magnum project.
> >
> > Feilong has contributed many features like Calico as an alternative CNI
> for
> > kubernetes, make coredns scale proportionally to the cluster, improved
> > admin operations on clusters and improved multi-master deployments. Apart
> > from contributing to the project he has been contributing to other
> projects
> > like gophercloud and shade, he has been very helpful with code reviews
> > and he tests and reviews all patches that are coming in. Finally, he is
> very
> > responsive on IRC and in the ML.
> >
> > Thanks for all your contributions Feilong, I'm looking forward to working
> > with
> > you more!
> >
> > Cheers,
> > Spyros
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Lingxian Kong]

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

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

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




Cheers,
Lingxian Kong

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

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

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

[Lingxian Kong]

Hi Ade,

Thanks for your reply.

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

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

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


Cheers,
Lingxian Kong

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

> Lingxian,
>
> I don't see any reason not to provide support for other wrapping
> mechanisms.
>
> Have you tried hacking the code to use one of the other wrapping
> mechanisms to see if it works?  Ultimately, what is passed are
> parameters to CFFI.  As long as you pass in the right input and your
> PKCS#11 library can support it, then there should be no problem.
>
> If it works, it makes sense to make the wrapping algorithm configurable
> for the plugin.
>
> It may or may not make sense to store the wrapping algorithm used in
> the secret plugin-metadata if we want to support migration to other
> HSMs.
>
> Ade
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Lingxian Kong]

Hi Barbican guys,

Currently, I am testing the integration between Barbican and SoftHSM v2 but
I met with a problem that SoftHSM v2 doesn't support CKM_AES_CBC_PAD key
wrapping operation which is hardcoded in Barbican code here
https://github.com/openstack/barbican/blob/5dea5cec130b59ecfb8d46435cd7eb3212894b4c/barbican/plugin/crypto/pkcs11.py#L496.
After discussion with SoftHSM team, I was told SoftHSM does support other
mechanisms such as CKM_AES_KEY_WRAP, CKM_AES_KEY_WRAP_PAD, CKM_RSA_PKCS, or
CKM_RSA_PKCS_OAEP.

My question is, is it easy to support other wrapping mechanisms in
Barbican? Or if there is another workaround this problem?

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

Re: [openstack-dev] [all][sdk] Integrating OpenStack and k8s with a service broker

[Lingxian Kong]

Hi Zane, please count me in :-)


Cheers,
Lingxian Kong

On Wed, Jun 6, 2018 at 4:52 AM, Remo Mattei  wrote:

> I will be happy to check it out.
>
> Remo
>
>
> On Jun 5, 2018, at 9:19 AM, Zane Bitter  wrote:
>
> I've been doing some investigation into the Service Catalog in Kubernetes
> and how we can get OpenStack resources to show up in the catalog for use by
> applications running in Kubernetes. (The Big 3 public clouds already
> support this.) The short answer is via an implementation of something
> called the Open Service Broker API, but there are shortcuts available to
> make it easier to do.
>
> I'm convinced that this is readily achievable and something we ought to do
> as a community.
>
> I've put together a (long-winded) FAQ below to answer all of your
> questions about it.
>
> Would you be interested in working on a new project to implement this
> integration? Reply to this thread and let's collect a list of volunteers to
> form the initial core review team.
>
> cheers,
> Zane.
>
>
> What is the Open Service Broker API?
> 
>
> The Open Service Broker API[1] is a standard way to expose external
> resources to applications running in a PaaS. It was originally developed in
> the context of CloudFoundry, but the same standard was adopted by
> Kubernetes (and hence OpenShift) in the form of the Service Catalog
> extension[2]. (The Service Catalog in Kubernetes is the component that
> calls out to a service broker.) So a single implementation can cover the
> most popular open-source PaaS offerings.
>
> In many cases, the services take the form of simply a pre-packaged
> application that also runs inside the PaaS. But they don't have to be -
> services can be anything. Provisioning via the service broker ensures that
> the services requested are tied in to the PaaS's orchestration of the
> application's lifecycle.
>
> (This is certainly not the be-all and end-all of integration between
> OpenStack and containers - we also need ways to tie PaaS-based applications
> into the OpenStack's orchestration of a larger group of resources. Some
> applications may even use both. But it's an important part of the story.)
>
> What sorts of services would OpenStack expose?
> --
>
> Some example use cases might be:
>
> * The application needs a reliable message queue. Rather than spinning up
> multiple storage-backed containers with anti-affinity policies and dealing
> with the overhead of managing e.g. RabbitMQ, the application requests a
> Zaqar queue from an OpenStack cloud. The overhead of running the queueing
> service is amortised across all of the applications in the cloud. The queue
> gets cleaned up correctly when the application is removed, since it is tied
> into the application definition.
>
> * The application needs a database. Rather than spinning one up in a
> storage-backed container and dealing with the overhead of managing it, the
> application requests a Trove DB from an OpenStack cloud.
>
> * The application includes a service that needs to run on bare metal for
> performance reasons (e.g. could also be a database). The application
> requests a bare-metal server from Nova w/ Ironic for the purpose. (The same
> applies to requesting a VM, but there are alternatives like KubeVirt -
> which also operates through the Service Catalog - available for getting a
> VM in Kubernetes. There are no non-proprietary alternatives for getting a
> bare-metal server.)
>
> AWS[3], Azure[4], and GCP[5] all have service brokers available that
> support these and many more services that they provide. I don't know of any
> reason in principle not to expose every type of resource that OpenStack
> provides via a service broker.
>
> How is this different from cloud-provider-openstack?
> 
>
> The Cloud Controller[6] interface in Kubernetes allows Kubernetes itself
> to access features of the cloud to provide its service. For example, if k8s
> needs persistent storage for a container then it can request that from
> Cinder through cloud-provider-openstack[7]. It can also request a load
> balancer from Octavia instead of having to start a container running
> HAProxy to load balance between multiple instances of an application
> container (thus enabling use of hardware load balancers via the cloud's
> abstraction for them).
>
> In contrast, the Service Catalog interface allows the *application*
> running on Kubernetes to access features of the cloud.
>
> What does a service broker look like?
> -
>
> A service broker provides an HTTP API with 5 actions:
>
&g

Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

[Lingxian Kong]

Thanks for your reply, @Doug and @Jim

Cheers,
Lingxian Kong


On Thu, May 17, 2018 at 2:23 AM Jim Rollenhagen <j...@jimrollenhagen.com>
wrote:

> On Wed, May 16, 2018 at 9:55 AM, Doug Hellmann <d...@doughellmann.com>
> wrote:
>
>> Excerpts from Lingxian Kong's message of 2018-05-16 11:12:01 +1200:
>> > Hi,
>> >
>> > Maybe I missed the original discussion, I found the 'mutable'
>> configuration
>> > implementation relies on oslo.service, but is there any guide for the
>> > projects using cotyledon instead?
>>
>> oslo.service implements the signal handler natively, but the feature
>> does not rely on oslo.service. The method in oslo.config that does the
>> work makes no assumptions about what triggers it. We did this on purpose
>> to support projects that do not use oslo.service.
>>
>> I don't know enough about cotyledon to tell you how to do it, but you
>> need to set up a signal handler so that SIGHUP invokes the
>> mutate_config_files() method of the ConfigOpts instance being used by
>> the application.
>>
>
> This was asked in another thread, see my reply :)
> http://lists.openstack.org/pipermail/openstack-dev/2018-March/128797.html
>
> // jim
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

[Lingxian Kong]

Hi,

Maybe I missed the original discussion, I found the 'mutable' configuration
implementation relies on oslo.service, but is there any guide for the
projects using cotyledon instead?

Cheers,
Lingxian Kong


On Wed, May 16, 2018 at 2:46 AM Doug Hellmann <d...@doughellmann.com> wrote:

> Excerpts from Lance Bragstad's message of 2018-05-14 18:45:49 -0500:
> >
> > On 05/14/2018 05:46 PM, Doug Hellmann wrote:
> > > Excerpts from Lance Bragstad's message of 2018-05-14 15:20:42 -0500:
> > >> On 05/14/2018 02:24 PM, Doug Hellmann wrote:
> > >>> Excerpts from Lance Bragstad's message of 2018-05-14 13:13:51 -0500:
> > >>>> On 03/19/2018 09:22 AM, Jim Rollenhagen wrote:
> > >>>>> On Sat, Mar 17, 2018 at 9:49 PM, Doug Hellmann <
> d...@doughellmann.com
> > >>>>> <mailto:d...@doughellmann.com>> wrote:
> > >>>>>
> > >>>>> Both of those are good ideas.
> > >>>>>
> > >>>>>
> > >>>>> Agree. I like the socket idea a bit more as I can imagine some
> > >>>>> operators don't want config file changes automatically applied. Do
> we
> > >>>>> want to choose one to standardize on or allow each project (or
> > >>>>> operators, via config) the choice?
> > >>>> Just to recap, keystone would be listening for when it's
> configuration
> > >>>> file changes, and reinitialize the logger if the logging settings
> > >>>> changed, correct?
> > >>> Sort of.
> > >>>
> > >>> Keystone would need to do something to tell oslo.config to re-load
> the
> > >>> config files. In services that rely on oslo.service, this is handled
> > >>> with a SIGHUP handler that calls ConfigOpts.mutate_config_files(), so
> > >>> for Keystone you would want to do something similar.
> > >>>
> > >>> That is, you want to wait for an explicit notification from the
> operator
> > >>> that you should reload the config, and not just watch for the file to
> > >>> change. We could talk about using file modification as a trigger, but
> > >>> reloading is something that may need to be staged across several
> > >>> services in order so we chose for the first version to make the
> trigger
> > >>> explicit. Relying on watching files will also fail when the modified
> > >>> data is not in a file (which will be possible when we finish the
> driver
> > >>> work described in
> > >>>
> http://specs.openstack.org/openstack/oslo-specs/specs/queens/oslo-config-drivers.html
> ).
> > >> Hmm, these are good points. I wonder if just converting to use
> > >> oslo.service would be a lower bar then?
> > > I thought keystone had moved away from that direction toward deploying
> > > only within Apache? I may be out of touch, or have misunderstood
> > > something, though.
> >
> > Oh - never mind... For some reason I was thinking there was a way to use
> > oslo.service and Apache.
> >
> > Either way, I'll do some more digging before tomorrow. I have this as a
> > topic on keystone's meeting agenda to go through our options [0]. If we
> > do come up with something that doesn't involve intercepting signals
> > (specifically for the reason noted by Kristi and Jim in the mod_wsgi
> > documentation), should the community goal be updated to include that
> > option? Just thinking that we can't be the only service in this position.
>
> I think we've left the implementation details up to the project
> teams, for just that reason. That said, it would be good to document
> how you do it (either formally or with a mailing list thread).
>
> And FWIW, if what you choose to do is monitor a file, that's fine
> as a trigger. I suggest not using the configuration file itself,
> though, for the reasons mentioned earlier.
>
> Doug
>
> PS - I wonder how Apache deals with reloading its own configuration
> file. Is there some sort of hook you could use?
>
> >
> > [0] https://etherpad.openstack.org/p/keystone-weekly-meeting
> >
> > >
> > > Doug
> > >
> > >
> __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Default scheduler filters survey

[Lingxian Kong]

At Catalyst Cloud:

RetryFilter
AvailabilityZoneFilter
RamFilter
ComputeFilter
AggregateCoreFilter
DiskFilter
AggregateInstanceExtraSpecsFilter
ImagePropertiesFilter
ServerGroupAntiAffinityFilter
SameHostFilter

Cheers,
Lingxian Kong


On Sat, Apr 28, 2018 at 3:04 AM Jim Rollenhagen <j...@jimrollenhagen.com>
wrote:

> On Wed, Apr 18, 2018 at 11:17 AM, Artom Lifshitz <alifs...@redhat.com>
> wrote:
>
>> Hi all,
>>
>> A CI issue [1] caused by tempest thinking some filters are enabled
>> when they're really not, and a proposed patch [2] to add
>> (Same|Different)HostFilter to the default filters as a workaround, has
>> led to a discussion about what filters should be enabled by default in
>> nova.
>>
>> The default filters should make sense for a majority of real world
>> deployments. Adding some filters to the defaults because CI needs them
>> is faulty logic, because the needs of CI are different to the needs of
>> operators/users, and the latter takes priority (though it's my
>> understanding that a good chunk of operators run tempest on their
>> clouds post-deployment as a way to validate that the cloud is working
>> properly, so maybe CI's and users' needs aren't that different after
>> all).
>>
>> To that end, we'd like to know what filters operators are enabling in
>> their deployment. If you can, please reply to this email with your
>> [filter_scheduler]/enabled_filters (or
>> [DEFAULT]/scheduler_default_filters if you're using an older version)
>> option from nova.conf. Any other comments are welcome as well :)
>>
>
> At Oath:
>
> AggregateImagePropertiesIsolation
> ComputeFilter
> CoreFilter
> DifferentHostFilter
> SameHostFilter
> ServerGroupAntiAffinityFilter
> ServerGroupAffinityFilter
> AvailabilityZoneFilter
> AggregateInstanceExtraSpecsFilter
>
> // jim
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [k8s][octavia][lbaas] Experiences on using the LB APIs with K8s

[Lingxian Kong]

Just FYI, l7 policy/rule support for Neutron LBaaS V2 and Octavia is on its
way[1], because we will have both octavia and magnum deployed on our
openstack based public cloud this year, an ingress controller for
openstack(octavia) is also on our TODO list, any kind of collaboration are
welcomed :-)

[1]: https://github.com/gophercloud/gophercloud/pull/833


Cheers,
Lingxian Kong (Larry)

On Fri, Mar 16, 2018 at 5:01 PM, Joe Topjian <j...@topjian.net> wrote:

> Hi Chris,
>
> I wear a number of hats related to this discussion, so I'll add a few
> points of view :)
>
> It turns out that with
>> Terraform, it's possible to tear down resources in a way that causes
>> Neutron to
>> leak administrator-privileged resources that can not be deleted by a
>> non-privileged users. In discussions with the Neutron and Octavia teams,
>> it was
>> strongly recommended that I move away from the Neutron LBaaSv2 API and
>> instead
>> adopt Octavia. Vexxhost graciously installed Octavia and my request and I
>> was
>> able to move past this issue.
>>
>
> Terraform hat! I want to slightly nit-pick this one since the words "leak"
> and "admin-priv" can sound scary: Terraform technically wasn't doing
> anything wrong. The problem was that Octavia was creating resources but not
> setting ownership to the tenant. When it came time to delete the resources,
> Octavia was correctly refusing, though it incorrectly created said
> resources.
>
> From reviewing the discussion, other parties were discovering this issue
> and patching in parallel to your discovery. Both xgerman and Vexxhost
> jumped in to confirm the behavior seen by Terraform. Vexxhost quickly
> applied the patch. It was a really awesome collaboration between yourself,
> dims, xgerman, and Vexxhost.
>
>
>> This highlights the first call to action for our public and private cloud
>> community: encouraging the rapid migration from older, unsupported APIs to
>> Octavia.
>>
>
> Operator hat! The clouds my team and I run are more compute-based. Our
> users would be more excited if we increased our GPU pool than enhanced the
> networking services. With that in mind, when I hear it said that "Octavia
> is backwards-compatible with Neutron LBaaS v2", I think "well, cool, that
> means we can keep running Neutron LBaaS v2 for now" and focus our efforts
> elsewhere.
>
> I totally get why Octavia is advertised this way and it's very much
> appreciated. When I learned about Octavia, my knee-jerk reaction was "oh
> no, not another load balancer" but that was remedied when I learned it's
> more like LBaaSv2++. I'm sure we'll deploy Octavia some day, but it's not
> our primary focus and we can still squeak by with Neutron's LBaaS v2.
>
> If you *really* wanted us to deploy Octavia ASAP, then a migration guide
> would be wonderful. I read over the "Developer / Operator Quick Start
> Guide" and found it very well written! I groaned over having to build an
> image but I also really appreciate the image builder script. If there can't
> be pre-built images available for testing, the second-best option is that
> script.
>
>
>> This highlights a second call to action for the SDK and provider
>> developers:
>> recognizing the end of life of the Neutron LBaaSv2 API[4][5] and adding
>> support for more advanced Octavia features.
>>
>
> Gophercloud hat! We've supported Octavia for a few months now, but purely
> by having the load-balancer client piggyback off of the Neutron LBaaS v2
> API. We made the decision this morning, coincidentally enough, to have
> Octavia be a first-class service peered with Neutron rather than think of
> Octavia as a Neutron/network child. This will allow Octavia to fully
> flourish without worry of affecting the existing LBaaS v2 API (which we'll
> still keep around separately).
>
> Thanks,
> Joe
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [qinling] Adding Hunt Xu to qinling core

[Lingxian Kong]

I'd like to add Hunt Xu to the qinling core team.

As you know, Qinling project was just approved as an official openstack
project, it's still very young and doesn't get a ton of activity or review,
but Hunt Xu has been involving in the development and improvement for
comparatively quite a while now:

http://stackalytics.com/report/contribution/qinling/30

He's currently working on improving the tests which is important for
Qinling at this stage (much appreciated!), we also need his vision and
passion for the project which is definitely required to be a core reviewer.

So unless there are objections, I'll plan on adding Hunt Xu to the qinling
group this week.

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

[openstack-dev] [qinling] project update - 4

[Lingxian Kong]

This project update email is supposed to be sent regularly, but feel free
to get in touch in #openstack-qinling irc channel anytime. - First, Qinling
was approved as an official project at the end of Queens cycle, and will
start its journey as an official project in Rocky development cycle,
welcome any kind of contributions from the whole community - Qinling
feature and bug tracking have been migrated from launchpad to
StoryBoard[1], which is much more flexible for task tracking across
multiple teams, multiple code repositories, or even multiple branches
within those code repositories. - The Rocky task priorities have been
sorted out, for anyone interested, please refer to
https://storyboard.openstack.org/#!/worklist/251 - More additional Jenkins
jobs were added to the project, such as doc, code coverage, release notes,
etc. As usual, you can easily find previous emails below. [1]:
https://storyboard.openstack.org/#!/project/927

Cheers,
Lingxian Kong (Larry)

-- Forwarded message --
From: Lingxian Kong <anlin.k...@gmail.com>
Date: Wed, Jan 24, 2018 at 12:12 AM
Subject: [openstack-dev] [faas] [qinling] project update - 3
To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>


Hi, all

This project update is posted bi-weekly, but feel free to get in touch in
#openstack-qinling anytime.


   - Function package md5 check. This feature allows user specify the md5
   checksum for the code package when creating the function, so the
   function package could be verified after downloading. If CLI is used, the
   md5 checksum will be calculated automatically.
   - Function webhook. The user can expose a function to 3rd party
   service(e.g. GitHub) by creating webhook so that the function can be
   invoked without authentication.
   - [CLI] Support to download function code package.


BTW, maybe some of you already know that Qinling team is applying to become
an OpenStack official project[1], feel free to leave your comments in the
application, any feedback and questions are welcomed.

As usual, you can easily find previous emails below.

[1]: https://review.openstack.org/#/c/533827/

Cheers,
Lingxian Kong (Larry)

-- Forwarded message --
From: Lingxian Kong <anlin.k...@gmail.com>
Date: Mon, Jan 8, 2018 at 10:37 AM
Subject: [openstack-dev] [faas] [qinling] project update - 2
To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>


Hi, all

Happy new year!

This project update is posted by-weekly, but feel free to get in touch in
#openstack-qinling anytime.

- Introduce etcd in qinling for distributed locking and storing the
resources that need to be updated frequently.
- Get function workers (admin only)
- Support to detach function from underlying orchestrator (admin only)
- Support positional args in users function
- More unit tests and functional tests added
- Powerful resource query filtering of qinling openstack CLI
- Conveniently delete all executions of one or more functions in CLI

You can find previous emails below.

Have a good day :-)

Cheers,
Lingxian Kong (Larry)

-- Forwarded message --
From: Lingxian Kong <anlin.k...@gmail.com>
Date: Tue, Dec 12, 2017 at 10:18 PM
Subject: [openstack-dev] [qinling] [faas] project update
​ - 1​

To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>


Hi, all

Maybe there are aleady some people interested in faas implementation in
openstack, and also deployed other openstack services to be integrated with
(e.g. trigger function by object uploading in swift), Qinling is the thing
you probably don't want to miss out. The main motivation I creatd Qinling
project is from frequent requirements of our public cloud customers.

For people who have not heard about Qinling before, please take a look at
my presentation in Sydney Summit:
https://youtu.be/NmCmOfRBlIU
There is also a simple demo video:
https://youtu.be/K2SiMZllN_A

As the first project update email, I will just list the features
implemented for now:

- Python runtime
- Sync/Async function execution
- Job (invoke function on schedule)
- Function defined in swift object storage service
- Function defined in docker image
- Easy to interact with openstack services in function
- Function autoscaling based on request rate
- RBAC operation
- Function resource limitation
- Simple documentation

I will keep posting the project update by-weekly, but feel free to get in
touch in #openstack-qinling anytime.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Qinling package description (was: Technical Committee Status update, February 2nd)

[Lingxian Kong]

Hi, Thomas,

Sorry for the inconvenience this new project brings to you, your ranting is
welcomed.

Currently, you can only refer to http://qinling.readthedocs.io/ for some
limited information about Qinling. I know lacking documentation is always a
problem for open source project, but we are trying our best to provide more
information in the near future, especially given it's an official project
now. You are also welcomed for contribution if you like, which is always
appreciated.

As for your question, only Python programming language is supported for now
in the upstream, but I recommend you do your own runtime implementation if
you are the cloud provider with your own cloud security consideration.
Actually, the runtime part is also pluggable in the codebase.

Again, documentation and more programming language support are
​ ​
definitely
two of the high priorities during Rocky dev cycle.
​ ​
Your feedback is important to us, feel free to pop up in #openstack-qinling
for chatting.

Cheers,
Lingxian Kong (Larry)

On Sun, Feb 4, 2018 at 12:07 AM, Thomas Goirand <z...@debian.org> wrote:

> On 02/02/2018 11:52 AM, Thierry Carrez wrote:
> > == Recently-approved changes ==
> >
> > * New project team: Qinling (Function as a Service) [1]
> > * Goal updates: ironic
> >
> > [1] https://review.openstack.org/#/c/533827/
>
> Sorry for this usual "no description" ranting, but I believe it's for
> the best.
>
> While Qinling seems a nice project, its description is IMO not very
> descriptive. I had to go on the AWS website to understand what AWS
> Lambda is. Nowhere, I could read what type of language Qinling supports.
> While I understand that a just born project cannot have a meaningful
> documentation, almost no project description isn't going to make it very
> attractive for new contributors.
>
> Could we get this improved?
>
> Cheers,
>
> Thomas Goirand (zigo)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [faas] [qinling] project update - 3

[Lingxian Kong]

Hi, all

This project update is posted bi-weekly, but feel free to get in touch in
#openstack-qinling anytime.


   - Function package md5 check. This feature allows user specify the md5
   checksum for the code package when creating the function, so the
   function package could be verified after downloading. If CLI is used, the
   md5 checksum will be calculated automatically.
   - Function webhook. The user can expose a function to 3rd party
   service(e.g. GitHub) by creating webhook so that the function can be
   invoked without authentication.
   - [CLI] Support to download function code package.


BTW, maybe some of you already know that Qinling team is applying to become
an OpenStack official project[1], feel free to leave your comments in the
application, any feedback and questions are welcomed.

As usual, you can easily find previous emails below.

[1]: https://review.openstack.org/#/c/533827/

Cheers,
Lingxian Kong (Larry)

-- Forwarded message --
From: Lingxian Kong <anlin.k...@gmail.com>
Date: Mon, Jan 8, 2018 at 10:37 AM
Subject: [openstack-dev] [faas] [qinling] project update - 2
To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>


Hi, all

Happy new year!

This project update is posted by-weekly, but feel free to get in touch in
#openstack-qinling anytime.

- Introduce etcd in qinling for distributed locking and storing the
resources that need to be updated frequently.
- Get function workers (admin only)
- Support to detach function from underlying orchestrator (admin only)
- Support positional args in users function
- More unit tests and functional tests added
- Powerful resource query filtering of qinling openstack CLI
- Conveniently delete all executions of one or more functions in CLI

You can find previous emails below.

Have a good day :-)

Cheers,
Lingxian Kong (Larry)

-- Forwarded message --
From: Lingxian Kong <anlin.k...@gmail.com>
Date: Tue, Dec 12, 2017 at 10:18 PM
Subject: [openstack-dev] [qinling] [faas] project update
​ - 1​

To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>


Hi, all

Maybe there are aleady some people interested in faas implementation in
openstack, and also deployed other openstack services to be integrated with
(e.g. trigger function by object uploading in swift), Qinling is the thing
you probably don't want to miss out. The main motivation I creatd Qinling
project is from frequent requirements of our public cloud customers.

For people who have not heard about Qinling before, please take a look at
my presentation in Sydney Summit:
https://youtu.be/NmCmOfRBlIU
There is also a simple demo video:
https://youtu.be/K2SiMZllN_A

As the first project update email, I will just list the features
implemented for now:

- Python runtime
- Sync/Async function execution
- Job (invoke function on schedule)
- Function defined in swift object storage service
- Function defined in docker image
- Easy to interact with openstack services in function
- Function autoscaling based on request rate
- RBAC operation
- Function resource limitation
- Simple documentation

I will keep posting the project update by-weekly, but feel free to get in
touch in #openstack-qinling anytime.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [mistral] Adding Adriano Petrich to the core team

[Lingxian Kong]

welcome to the team, Adriano!


Cheers,
Lingxian Kong (Larry)

On Mon, Jan 15, 2018 at 10:11 PM, Renat Akhmerov <renat.akhme...@gmail.com>
wrote:

> Hi,
>
> I’d like to promote Adriano Petrich to the Mistral core team. Adriano has
> shown the good review rate and quality at least over the last two cycles
> and implemented several important features (including new useful YAQL/JINJA
> functions).
>
> Please vote whether you agree to add Adriano to the core team.
>
> Adriano’s statistics: http://stackalytics.com/?module=
> mistral-group=queens_id=apetrich
>
> Thanks
>
> Renat Akhmerov
> @Nokia
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kubernetes-python-client] Failed to get service list

[Lingxian Kong]

Thanks for the reminder, Michal.

I sent the email here because the client library is dependency of several
openstack projects, the issue I found may cause potential problems to them,
and I also want to get some hints if they already solved that.


Cheers,
Lingxian Kong (Larry)

On Thu, Jan 11, 2018 at 3:58 AM, Michal Rostecki <mroste...@suse.com> wrote:

> On 01/10/2018 07:40 AM, Lingxian Kong wrote:
> > I submitted an issue in github[1] the other day but didn't get any
> > response, try my luck to attract attention here in case someone else has
> > the same problem or already has a solution I didn't know, or hopefully, I
> > missed something.
> >
>
> This is not the correct mailing list to talk about that project.
> Kubernetes-incubator is a part of Kubernetes community, not OpenStack.
> If you have a problem with reaching developers of python-client on github,
> I recommend to use Kubernetes Slack.
>
> Cheers,
> Michal
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kubernetes-python-client] Failed to get service list

[Lingxian Kong]

I submitted an issue in github[1] the other day but didn't get any
response, try my luck to attract attention here in case someone else has
the same problem or already has a solution I didn't know, or hopefully, I
missed something.

The problem is when I want to get service list(the result should be an
empty list), but I met with the following exception:

2018-01-10 06:31:58.930 6417 ERROR oslo_messaging.rpc.server   File
>> "/usr/local/lib/python2.7/dist-packages/kubernetes/client/apis/core_v1_api.py",
>> line 12951, in list_namespaced_service
>
> 2018-01-10 06:31:58.930 6417 ERROR oslo_messaging.rpc.server (data) =
>> self.list_namespaced_service_with_http_info(namespace, **kwargs)
>
> 2018-01-10 06:31:58.930 6417 ERROR oslo_messaging.rpc.server   File
>> "/usr/local/lib/python2.7/dist-packages/kubernetes/client/apis/core_v1_api.py",
>> line 13054, in list_namespaced_service_with_http_info
>
> 2018-01-10 06:31:58.930 6417 ERROR oslo_messaging.rpc.server
>>  collection_formats=collection_formats)
>
> 2018-01-10 06:31:58.930 6417 ERROR oslo_messaging.rpc.server   File
>> "/usr/local/lib/python2.7/dist-packages/kubernetes/client/api_client.py",
>> line 321, in call_api
>
> 2018-01-10 06:31:58.930 6417 ERROR oslo_messaging.rpc.server
>>  _return_http_data_only, collection_formats, _preload_content,
>> _request_timeout)
>
> 2018-01-10 06:31:58.930 6417 ERROR oslo_messaging.rpc.server   File
>> "/usr/local/lib/python2.7/dist-packages/kubernetes/client/api_client.py",
>> line 163, in __call_api
>
> 2018-01-10 06:31:58.930 6417 ERROR oslo_messaging.rpc.server
>>  return_data = self.deserialize(response_data, response_type)
>
> 2018-01-10 06:31:58.930 6417 ERROR oslo_messaging.rpc.server   File
>> "/usr/local/lib/python2.7/dist-packages/kubernetes/client/api_client.py",
>> line 236, in deserialize
>
> 2018-01-10 06:31:58.930 6417 ERROR oslo_messaging.rpc.server return
>> self.__deserialize(data, response_type)
>
> 2018-01-10 06:31:58.930 6417 ERROR oslo_messaging.rpc.server   File
>> "/usr/local/lib/python2.7/dist-packages/kubernetes/client/api_client.py",
>> line 276, in __deserialize
>
> 2018-01-10 06:31:58.930 6417 ERROR oslo_messaging.rpc.server return
>> self.__deserialize_model(data, klass)
>
> 2018-01-10 06:31:58.930 6417 ERROR oslo_messaging.rpc.server   File
>> "/usr/local/lib/python2.7/dist-packages/kubernetes/client/api_client.py",
>> line 622, in __deserialize_model
>
> 2018-01-10 06:31:58.930 6417 ERROR oslo_messaging.rpc.server instance
>> = klass(**kwargs)
>
> 2018-01-10 06:31:58.930 6417 ERROR oslo_messaging.rpc.server   File
>> "/usr/local/lib/python2.7/dist-packages/kubernetes/client/models/v1_service_list.py",
>> line 60, in __init__
>
> 2018-01-10 06:31:58.930 6417 ERROR oslo_messaging.rpc.server
>>  self.items = items
>
> 2018-01-10 06:31:58.930 6417 ERROR oslo_messaging.rpc.server   File
>> "/usr/local/lib/python2.7/dist-packages/kubernetes/client/models/v1_service_list.py",
>> line 110, in items
>
> 2018-01-10 06:31:58.930 6417 ERROR oslo_messaging.rpc.server raise
>> ValueError("Invalid value for `items`, must not be `None`")
>
> 2018-01-10 06:31:58.930 6417 ERROR oslo_messaging.rpc.server ValueError:
>> Invalid value for `items`, must not be `None`
>
>
[1]: https://github.com/kubernetes-incubator/client-python/issues/424

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

[openstack-dev] [faas] [qinling] project update - 2

[Lingxian Kong]

Hi, all

Happy new year!

This project update is posted by-weekly, but feel free to get in touch in
#openstack-qinling anytime.

- Introduce etcd in qinling for distributed locking and storing the
resources that need to be updated frequently.
- Get function workers (admin only)
- Support to detach function from underlying orchestrator (admin only)
- Support positional args in users function
- More unit tests and functional tests added
- Powerful resource query filtering of qinling openstack CLI
- Conveniently delete all executions of one or more functions in CLI

You can find previous emails below.

Have a good day :-)

Cheers,
Lingxian Kong (Larry)

-- Forwarded message --
From: Lingxian Kong <anlin.k...@gmail.com>
Date: Tue, Dec 12, 2017 at 10:18 PM
Subject: [openstack-dev] [qinling] [faas] project update
​ - 1​

To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>


Hi, all

Maybe there are aleady some people interested in faas implementation in
openstack, and also deployed other openstack services to be integrated with
(e.g. trigger function by object uploading in swift), Qinling is the thing
you probably don't want to miss out. The main motivation I creatd Qinling
project is from frequent requirements of our public cloud customers.

For people who have not heard about Qinling before, please take a look at
my presentation in Sydney Summit:
https://youtu.be/NmCmOfRBlIU
There is also a simple demo video:
https://youtu.be/K2SiMZllN_A

As the first project update email, I will just list the features
implemented for now:

- Python runtime
- Sync/Async function execution
- Job (invoke function on schedule)
- Function defined in swift object storage service
- Function defined in docker image
- Easy to interact with openstack services in function
- Function autoscaling based on request rate
- RBAC operation
- Function resource limitation
- Simple documentation

I will keep posting the project update by-weekly, but feel free to get in
touch in #openstack-qinling anytime.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] propose to upgrade python kubernetes (the k8s python client) to 4.0.0 which breaks oslo.service

[Lingxian Kong]

Thanks, leyal. I've already changed the service framework from oslo.service
to cotyledon https://review.openstack.org/#/c/530428/, and it works
perfectly fine.


Cheers,
Lingxian Kong (Larry)

On Mon, Jan 8, 2018 at 2:47 AM, Eyal Leshem <ey.les...@gmail.com> wrote:

> Hi Lingxian,
>
> I uploaded a patch for kuryr-kubernetes  that monkey-patch the ThreadPool
> with
> GreenPool (https://review.openstack.org/#/c/530655/4/kuryr_kubernetes/
> thread_pool_patch.py).
>
> It's support only apply_async - but that should be enough for k8s.
>
> That can be dangers - if you use ThreadPool in other places in your code,
> but in such case you can't run with eventlet anyway.
>
> hope that helps,
> leyal
>
>
>
>
> On 4 January 2018 at 23:45, Lingxian Kong <anlin.k...@gmail.com> wrote:
>
>> On Tue, Jan 2, 2018 at 1:56 AM, Eyal Leshem <ey.les...@gmail.com> wrote:
>>
>>> Hi ,
>>>
>>> According to https://github.com/eventlet/eventlet/issues/147 - it's
>>> looks that eventlet
>>> has issue with "multiprocessing.pool".
>>>
>>> The ThreadPool used in code that auto-generated by swagger.
>>>
>>> Possible workaround for that is to monky-patch the client library ,
>>> and replace the pool with greenpool.
>>>
>>
>> Hi, leyal, I'm not very familar with eventlet, but how can I monkey patch
>> kubernetes python lib?
>> The only way I can see now is to replace oslo.service with something
>> else, e.g. cotyledon, avoid to use eventlet, that's a signaficant change
>> though. I also found this bug https://bugs.launchpad.net
>> /taskflow/+bug/1225275 in taskflow, they chose to not use
>> multiprocessing module.
>>
>> Any other suggestions are welcomed!
>>
>>
>>>
>>> If someone has better workaround, please share that with us :)
>>>
>>> btw , I don't think that should be treated as compatibility issue
>>> in the client python as it's an eventlet issue..
>>>
>>> Thanks ,
>>> leyal
>>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] propose to upgrade python kubernetes (the k8s python client) to 4.0.0 which breaks oslo.service

[Lingxian Kong]

On Tue, Jan 2, 2018 at 1:56 AM, Eyal Leshem  wrote:

> Hi ,
>
> According to https://github.com/eventlet/eventlet/issues/147 - it's looks
> that eventlet
> has issue with "multiprocessing.pool".
>
> The ThreadPool used in code that auto-generated by swagger.
>
> Possible workaround for that is to monky-patch the client library ,
> and replace the pool with greenpool.
>

Hi, leyal, I'm not very familar with eventlet, but how can I monkey patch
kubernetes python lib?
The only way I can see now is to replace oslo.service with something else,
e.g. cotyledon, avoid to use eventlet, that's a signaficant change though.
I also found this bug https://bugs.launchpad.net/taskflow/+bug/1225275 in
taskflow, they chose to not use multiprocessing module.

Any other suggestions are welcomed!


>
> If someone has better workaround, please share that with us :)
>
> btw , I don't think that should be treated as compatibility issue
> in the client python as it's an eventlet issue..
>
> Thanks ,
> leyal
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] propose to upgrade python kubernetes (the k8s python client) to 4.0.0 which breaks oslo.service

[Lingxian Kong]

I edited the topic just for attention.

However, the new kubernetes client version breaks the services that's using
oslo.service which relies on eventlet library. Some error logs below:

(Pdb) n
> /vagrant/qinling/qinling/orchestrator/kubernetes/manager.py(49)__init__()
-> client = api_client.ApiClient(configuration=config)
(Pdb) n
Exception in thread Thread-2:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner
self.run()
  File "/usr/lib/python2.7/threading.py", line 754, in run
self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib/python2.7/multiprocessing/pool.py", line 325, in
_handle_workers
while thread._state == RUN or (pool._cache and thread._state !=
TERMINATE):
AttributeError: '_MainThread' object has no attribute '_state'

I did a google search, found this:
https://github.com/eventlet/eventlet/issues/147

multiprocessing.pool was introduced since 4.0.0 (threading lib was used
before)

I assume this is an backward incompatible change.

Any suggestion?

Cheers,
Lingxian Kong (Larry)

On Wed, Dec 13, 2017 at 10:41 PM, Eyal Leshem <ey.les...@gmail.com> wrote:

> Hi Lingxian,
>
> It's should -  under the assumption of uses only the v1 models ( and not
> v1_alpha or v1_beta).
> see : https://kubernetes.io/docs/reference/api-overview/
>
> thanks ,
> leyal
>
> On 13 December 2017 at 11:16, Lingxian Kong <anlin.k...@gmail.com> wrote:
>
>> hi, leyal,
>>
>> I suppose the upgrade is backward compatible, right?
>>
>>
>> Cheers,
>> Lingxian Kong (Larry)
>>
>> On Wed, Dec 13, 2017 at 8:51 PM, Eyal Leshem <ey.les...@gmail.com> wrote:
>>
>>> Hi all ,
>>>
>>> In order to use kubernetes client that support network-policies ,
>>> we plan to upgrade the python kubernetes package  from  1.0.0 to 4.0.0.
>>>
>>> any objections ?
>>>
>>> thanks,
>>> leyal
>>>
>>> clarification:
>>> The purposed changed is for kubernetes-python-client - that called just
>>>  "kubernetes" in  pypi
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] propose to upgrade python kubernetes (the k8s python client) to 4.0.0

[Lingxian Kong]

cool, thanks!


Cheers,
Lingxian Kong (Larry)

On Wed, Dec 13, 2017 at 10:41 PM, Eyal Leshem <ey.les...@gmail.com> wrote:

> Hi Lingxian,
>
> It's should -  under the assumption of uses only the v1 models ( and not
> v1_alpha or v1_beta).
> see : https://kubernetes.io/docs/reference/api-overview/
>
> thanks ,
> leyal
>
> On 13 December 2017 at 11:16, Lingxian Kong <anlin.k...@gmail.com> wrote:
>
>> hi, leyal,
>>
>> I suppose the upgrade is backward compatible, right?
>>
>>
>> Cheers,
>> Lingxian Kong (Larry)
>>
>> On Wed, Dec 13, 2017 at 8:51 PM, Eyal Leshem <ey.les...@gmail.com> wrote:
>>
>>> Hi all ,
>>>
>>> In order to use kubernetes client that support network-policies ,
>>> we plan to upgrade the python kubernetes package  from  1.0.0 to 4.0.0.
>>>
>>> any objections ?
>>>
>>> thanks,
>>> leyal
>>>
>>> clarification:
>>> The purposed changed is for kubernetes-python-client - that called just
>>>  "kubernetes" in  pypi
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] propose to upgrade python kubernetes (the k8s python client) to 4.0.0

[Lingxian Kong]

hi, leyal,

I suppose the upgrade is backward compatible, right?


Cheers,
Lingxian Kong (Larry)

On Wed, Dec 13, 2017 at 8:51 PM, Eyal Leshem <ey.les...@gmail.com> wrote:

> Hi all ,
>
> In order to use kubernetes client that support network-policies ,
> we plan to upgrade the python kubernetes package  from  1.0.0 to 4.0.0.
>
> any objections ?
>
> thanks,
> leyal
>
> clarification:
> The purposed changed is for kubernetes-python-client - that called just
>  "kubernetes" in  pypi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [qinling] [faas] project update

[Lingxian Kong]

Hi, all

Maybe there are aleady some people interested in faas implementation in
openstack, and also deployed other openstack services to be integrated with
(e.g. trigger function by object uploading in swift), Qinling is the thing
you probably don't want to miss out. The main motivation I creatd Qinling
project is from frequent requirements of our public cloud customers.

For people who have not heard about Qinling before, please take a look at
my presentation in Sydney Summit:
https://youtu.be/NmCmOfRBlIU
There is also a simple demo video:
https://youtu.be/K2SiMZllN_A

As the first project update email, I will just list the features
implemented for now:

- Python runtime
- Sync/Async function execution
- Job (invoke function on schedule)
- Function defined in swift object storage service
- Function defined in docker image
- Easy to interact with openstack services in function
- Function autoscaling based on request rate
- RBAC operation
- Function resource limitation
- Simple documentation

I will keep posting the project update by-weekly, but feel free to get in
touch in #openstack-qinling anytime.

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

Re: [openstack-dev] [faas] [qinling] demo video

[Lingxian Kong]

On Tue, Nov 14, 2017 at 5:24 AM, Belmiro Moreira <
moreira.belmiro.email.li...@gmail.com> wrote:

> Hi,
> just started to look what's available as Functions as a Service in
> OpenStack.
> Thanks for the demo.
>
> What's the difference between "qinling" and "picasso"?
>

​Thanks for asking this question :-)​

​When I started to look at FaaS in OpenStack, picasso is the first thing I
evaluated. Technically, it's a very thin layer of picasso api, just
integrated with Keystone authentication, you still need to rely on
IronFunctions (open source version of the company Iron.io's commercial
product) service to make it work.​ What's more, I don't think that project
is actively maintained and the code style/python lib usage do not comply
with openstack 'best practise'.

Qinling is kind of 'neutral' project that can rely on different open source
container technologies (k8s, swarm, zun, etc.) using plugin mechanisam
rather than being locked in by 3rd party commercial products or open source
projects mainly maintained by one company. It's being developed tightly
with openstack community, it's using oslo libraries, zuul v3, openstack
style documenation, code style, irc channel, etc. Most importantly, it can
be integrated very well with other openstack services (Swift, Zaqar,
Ceilometer, Aodh, etc.)

I am developing this project because as an OpenStack based public cloud
provider we have FaaS requirement from our customers, and 'upstream first'
is our commitment as an open source company.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [faas] [qinling] demo video

[Lingxian Kong]

Hi, all

For those who are interested in Qinling project (and its integration with
other OpenStack services), I recorded the demo in my summit
presentation[1], which is very similar to the use case of integration
between AWS Lambda and S3.

https://youtu.be/K2SiMZllN_A

If you have any questions about Qinling, feel free to ask in
#openstack-qinling irc channel, my irc name is kong. I am always online
from UTC 20:30 to UTC 04:00, but you can leave messages to me anyway.

[1]:
https://www.openstack.org/videos/sydney-2017/make-your-application-serverless

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

Re: [openstack-dev] Project Ideas for Graduate Student

[Lingxian Kong]

Security? Maybe Barbican project is a good start :-)


Cheers,
Lingxian Kong (Larry)

On Thu, Oct 5, 2017 at 10:59 PM, Puneet Jain <punitj...@csu.fullerton.edu>
wrote:

> Hello all,
>
> I am a graduate student and have intermediate knowledge and huge in cloud
> computing. I am looking for a project idea, particularly any new feature I
> can implement in OpenStack.
>
> I thought of implementing multi-factor authentication but happened to know
> that it has already been implemented.  https://docs.openstack.org/
> security-guide/identity/authentication.html
>
> I would prefer to do something in security. Any ideas?
>
> Looking forward to hearing from you guys. Thanks in advance!
>
> --
> ​Best ​
> Regards,
> Puneet Jain
>
> <https://www.linkedin.com/pub/puneet-jain/20/917/a54>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [octavia][heat] Octavia deployment with Heat

[Lingxian Kong]

BTW, may I ask if Heat(master) already supports Octavia V2 API? If no, is
there anyone working on that or it's on the TODO list? Thanks!


Cheers,
Lingxian Kong (Larry)

On Thu, Sep 14, 2017 at 6:11 PM, <mihaela.ba...@orange.com> wrote:

> Hello,
>
>
>
> Are there any plans to fix this in Heat?
>
>
>
> Thank you,
>
> Mihaela Balas
>
>
>
> *From:* Rabi Mishra [mailto:ramis...@redhat.com]
> *Sent:* Wednesday, July 26, 2017 3:43 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [octavia][heat] Octavia deployment with
> Heat
>
>
>
> On Wed, Jul 26, 2017 at 5:34 PM, <mihaela.ba...@orange.com> wrote:
>
> Hello,
>
>
>
> Is Octavia (Ocata version) supposed to work with Heat (tested with Newton
> version) deployment? I launch a Heat stack trying to deploy a load balancer
> with a single listener/pool and two members. While the Heat shows status
> COMPLETE and the Neutron shows all objects as created, Octavia creates the
> listener, the pool but with a single member (instead of two).
>
> Another example: I launch a Heat stack trying to deploy a load balancer
> with a multiple listeners/pools each having two members. The results is
> that Heat shows status COMPLETE and the Neutron shows all objects as
> created, Octavia creates the listeners, but only some of the pools and for
> those pool creates only one member or none.
>
> In the Octavia log I could see only these type of errors:
>
>
>
> Sounds like https://bugs.launchpad.net/heat/+bug/1632054.
>
> We just check provisioning_status of the loadbalancer when adding members
> and mark the resource as CREATE_COMPLETE.  I think octavia had added
> provisioning_status for all top level objects like listener etc[1], but I
> don't think those attributes are available with lbaasv2 api for us to check.
>
> [1] https://review.openstack.org/#/c/372791/
>
>
>
> 2017-07-26 08:12:08.639 1 INFO octavia.api.v1.controllers.member
> [req-749be397-dd63-4fb6-9d86-b717f6d59e3d - 989bbadfe4134722b478ca799217833e
> - default default] Member cannot be created or modified because the Load
> Balancer is in an immutable state
>
> 2017-07-26 08:12:08.698 1 DEBUG wsme.api 
> [req-749be397-dd63-4fb6-9d86-b717f6d59e3d
> - 989bbadfe4134722b478ca799217833e - default default] Client-side error:
> Load Balancer b12a29db-81d0-451a-af9c-d563b636bf01 is immutable and
> cannot be updated. format_exception /opt/octavia/lib/python2.7/
> site-packages/wsme/api.py:222
>
>
>
> I think what happens is that it takes some time until the configuration is
> updated on an amphora and during that time the Load Balancer is in UPDATE
> state and new configuration cannot be added.
>
>
>
> Is this scenario validated or it is still work in progress?
>
>
>
> Thanks,
>
> Mihaela Balas
>
>
>
>
>
> _
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
>
> Thank you.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electron

Re: [openstack-dev] [all] connecting nova notification users and developers

[Lingxian Kong]

On Sat, Sep 2, 2017 at 1:28 AM, gordon chung  wrote:

>
>
> On 2017-08-30 10:30 AM, Balazs Gibizer wrote:
> > 1) We in the nova developer community would like to see which projects
> > are using (or planning to use) the nova notification interface. Also we
> > would like to know if you are using the legacy unversioned notifications
> > or the new versioned ones. We would like to know what are your use cases
> > towards our notification interface and we also would like to get any
> > type of feedback about the interface (both the old and the new one).
> > Based on this information we can make better decision where to focus our
> > development effort. As a good example we already have a  cooperation
> > with the searchlight project to enhance nova's versioned notification
> > interface based on their needs [3].
>
> ceilometer uses it to create events and meters. events just capture the
> message as is and might strip out some superfluous details. meters are
> numerical values (associated with time). in both cases, we have yaml
> files where we just define 'if message event_type equals blah, strip out
> values x, y, and z'[1][2]


​Hi Gordon, does Aodh rely on Ceilometer to receive events or it could
receive notifications directly from other services?​
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] Multi-region support in shared Keystone service deployment

[Lingxian Kong]

Thanks, Rob, blueprint is proposed here:
https://blueprints.launchpad.net/horizon/+spec/horizon-multi-region-support


Cheers,
Lingxian Kong (Larry)

On Thu, Aug 17, 2017 at 11:05 PM, Rob Cresswell (rcresswe) <
rcres...@cisco.com> wrote:

> As I mentioned the last time you asked :), we use blueprints, and the
> template is here: https://blueprints.launchpad.net/horizon/+spec/template
>
> Please register a blueprint for discussion / tracking. The change looks
> sensible, although I’d prefer we use a setting name like
> https://docs.openstack.org/horizon/latest/configuration/settings.html#
> openstack-keystone-domain-choices. It’s a bit less ambiguous.
>
> Rob
>
>
>
> On 16 Aug 2017, at 23:03, Lingxian Kong <anlin.k...@gmail.com> wrote:
>
> Hi, Horizon developers,
>
> In our OpenStack based public cloud(Catalyst Cloud), Keystone is a shared
> identity service across 3 regions, our customers have been asking for the
> feature that they could select their preferred region when they log in
> Horizon, rather than switching region each time after login.
>
> Unfortunately, the existing 'AVAILABLE_REGIONS' only works with
> multi-keystone, multi-region environment, so for backward compatibility and
> getting rid of potential confusion, a new config option named
> 'AVAILABLE_SERVICE_REGIONS' was introduced in my patch[1][2], the setting
> is supposed to be configured by the cloud operators and the
> 'AVAILABLE_REGIONS' setting will take precedence over
> 'AVAILABLE_SERVICE_REGIONS'.
>
> I am sending this email to ask for more feedback, and do I need to propose
> a feature spec before the code is actually being reviewed?
>
> [1]: https://review.openstack.org/#/c/494083/
> [2]: https://review.openstack.org/#/c/494059/
>
> Cheers,
> Lingxian Kong (Larry)
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [horizon] Multi-region support in shared Keystone service deployment

[Lingxian Kong]

Hi, Horizon developers,

In our OpenStack based public cloud(Catalyst Cloud), Keystone is a shared
identity service across 3 regions, our customers have been asking for the
feature that they could select their preferred region when they log in
Horizon, rather than switching region each time after login.

Unfortunately, the existing 'AVAILABLE_REGIONS' only works with
multi-keystone, multi-region environment, so for backward compatibility and
getting rid of potential confusion, a new config option named
'AVAILABLE_SERVICE_REGIONS' was introduced in my patch[1][2], the setting
is supposed to be configured by the cloud operators and the
'AVAILABLE_REGIONS' setting will take precedence over
'AVAILABLE_SERVICE_REGIONS'.

I am sending this email to ask for more feedback, and do I need to propose
a feature spec before the code is actually being reviewed?

[1]: https://review.openstack.org/#/c/494083/
[2]: https://review.openstack.org/#/c/494059/

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

Re: [openstack-dev] [mistral][core] Proposing Andras Kovi to the Mistral core team

[Lingxian Kong]

+1, It will be great to have him!


Cheers,
Lingxian Kong (Larry)

On Thu, Aug 10, 2017 at 5:34 PM, Renat Akhmerov <renat.akhme...@gmail.com>
wrote:

> Hi,
>
> I’d like to propose Andras Kovi to the Mistral core team.
>
> The current statistics of Andras can be seen at [1].
> Andras has been contributing for about 1.5 years and in Pike he increased
> his activity significantly, primarily reviewing. His reviews are always
> thorough and insightful. He cares about code quality. He knows both
> OpenStack ecosystem and Mistral architecture and codebase well. Adding
> Andras to the core team would be also very useful for us because he is a
> very active user of Mistral, he implemented or participated in
> implementation of lots of Nokia CBAM use cases based on Mistral.
> Andras also gave an excellent presentation about Mistral performance in
> Boston, [2]. I’d really recommend to watch it if you work with Mistral as a
> contributor or as a user.
> Speaking less formally, Andras is a very good guy, deep thinker with a
> great experience in software programming. Every time I have a chance to
> meet him personally it’s a lot of fun to talk to him and learn from him.
>
> So I’m asking you to support me in this promotion. I really believe that
> Andras will be an invaluable addition to our team.
>
> [1] http://stackalytics.com/?module=mistral-group_id=akovi
> [2] https://www.openstack.org/videos/boston-2017/mistral-
> performance-in-numbers
>
> Thanks
>
> Renat Akhmerov
> @Nokia
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [mistral] External GUI for Mistral is now at github

[Lingxian Kong]

That's awesome! It'd be better if there is a demo for introduction :-)


Cheers,
Lingxian Kong (Larry)

On Tue, Jul 4, 2017 at 9:48 PM, Shaanan, Guy (Nokia - IL/Kfar Sava) <
guy.shaa...@nokia.com> wrote:

> Hi all,
>
>
>
> We are happy to announce “CloudFlow”- a Mistral Workflow Execution
> Visualization tool, to help you debug and monitor in real time the progress
> of executions.
>
>
>
> CloudFlow offers web based GUI and relies on Mistral REST API.
>
>
>
> CloudFlow source code is publicly available on github[1].
>
>
>
> With this move we can now leverage the project management options in
> Github, like:
>
> * Projects[2] - managing the backlog, todos and in-progress tasks.
>
> * Issues[3] - for opening bugs and feature requests.
>
>
>
> Contributions should be made via a PR and code review, after an
> appropriate task has been added to Projects or a bug has been opened.
>
>
>
> Currently the building and publishing of new versions is done manually and
> will be automated in the future.
>
>
>
>
>
> [1] https://github.com/nokia/CloudFlow
>
> [2] https://github.com/nokia/CloudFlow/projects/1
>
> [3] https://github.com/nokia/CloudFlow/issues
>
>
>
> Thanks,
>
>
>
> *-*
>
> *Guy Shaanan*
>
> CI & Internal Tools
>
> Application & Analytics, Nokia
>
> 16 Atir Yeda St. Kfar-Saba 44643, ISRAEL
>
> T: +972 9 793 3013
>
> M: +972 52 536 2986 <+972%2052-536-2986>
>
> guy.shaa...@nokia.com
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][all][ptl] Most Supported Queens Goals and Improving Goal Completion

[Lingxian Kong]

I like the idea, which means some projects lack of resources could benefit
more from the whole community :)


Cheers,
Lingxian Kong (Larry)

On Fri, Jun 23, 2017 at 5:57 AM, Mike Perez <thin...@gmail.com> wrote:

> Hey all,
>
> In the community wide goals, we started as a group discussing goals at the
> OpenStack Forum. Then we brought those ideas to the mailing list to
> continue the discussion and include those that were not able to be at the
> forum. The discussions help the TC decide on what goals we will do for the
> Queens release. The goals that have the most support so far are:
>
> 1) Split Tempest plugins into separate repos/projects [1]
> 2) Move policy and policy docs into code [2]
>
> In the recent TC meeting [3] it was recognized that goals in Pike haven't
> been going as smoothly and not being completed. There will be a follow up
> thread to cover gathering feedback in an etherpad later, but for now the TC
> has discussed potential actions to improve completing goals in Queens.
>
> An idea that came from the meeting was creating a role of "Champions", who
> are the drum beaters to get a goal done by helping projects with tracking
> status and sometimes doing code patches. These would be interested
> volunteers who have a good understanding of their selected goal and its
> implementation to be a trusted person.
>
> What do people think before we bikeshed on the name? Would having a
> champion volunteer to each goal to help? Are there ideas that weren't
> mentioned in the TC meeting [3]?
>
> [1] - https://governance.openstack.org/tc/goals/queens/
> split-tempest-plugins.html
> [2] - https://www.mail-archive.com/openstack-dev@lists.
> openstack.org/msg106392.html
> [3] - http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-
> 06-20-20.01.log.html#l-10
>
> —
> Mike Perez
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [FaaS] Introduce a FaaS project

[Lingxian Kong]

Hi, Rob,

Appreciate your suggestions. Please see my inline comments.

On Mon, May 15, 2017 at 11:17 PM, Robert Putt <robert.p...@rackspace.co.uk>
wrote:

> For me the important things are:
>
>
>
> a)   Sandboxed code in some container solution
>
Yeah, it's on the roadmap (may happen in several days.)

> b)   Pluggable backends for said sandbox to remove vendor lock in
>
c)   Pluggable storage for function packages, the default probably
> being Swift
>
Qinling already supports plugable storage. In order to make it easy to
test, the default is local file system. But it's up to deployer to decide
which storage solution to use.

> d)   Integration with Keystone for auth and role based access control
> e.g. sharing functions with other tenants but maybe with different
> permissions, e.g. dev tenant in a domain can publish functions but prod
> tenant can only execute the functions.
>
Qinling supports Keystone for authentication. RBAC is on the roadmap.

> e)   Integration with Neutron so functions can access tenant networks.
>
This needs to be discussed further. Currently, the code is executed inside
container which locates in orchestration system. Not sure it's easy to make
that container access tenant network.

> f)A web services gateway to create RESTful APIs and map URIs /
> verbs / API requests to functions.
>
Currently, user could invoke function by calling Qinling's rest api, but I
agree with you that an API Gateway service is indeed necessary to provide
more flexibility to end users.

> g)   It would also be nice to have some meta data service like what
> we see in Nova so functions can have an auto injected context relating to
> the tenant running it rather than having to inject all parameters via the
> API.
>

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

Re: [openstack-dev] [FaaS] Introduce a FaaS project

[Lingxian Kong]

On Mon, May 15, 2017 at 8:32 PM, Sam P  wrote:

> Hi Larry,
>  Thank you for the details.
>  I am interested and like the idea of no vendor/platform lock-in.
>
>  However,  I still have this stupid question in me.
>  Why FaaS need to be in the OpenStack ecosystem? Can it survive
> outside and still be able to integrate with OpenStack?
>

In OpenStack ecosystem, I mean put this project under OpenStack umbrella so
that it could leverage OpenStack facilities, and integrating with other
OpenStack services means it is an option to be deployed together with them
and be triggered by event/notification from them.


>  This FaaS must able to well integrated with OpenStack ecosystem and
> no argument there.
>
> >>IMHO, none of them can be well integrated with OpenStack ecosystem.
> Can you share more details on this?  If you have done any survey on
> this,  please share.
> Crating FaaS with pure OpenStack means, we need to create something
> similar to OpenWhisk or IronFunctions with existing or new OpenStack
> components.
> I just want to make sure it is worth it to recreate the wheels.
>

Yeah, you are right, as I said at the beginning, I'm sort of recreating the
wheels. I hope the new project can be easily installed together with other
OpenStack projects using similar methodology, it can provide a beautiful
RESTful API to end users, it's easy for OpenStack developers to understand
and maintain. I don't think it is that easy if we go with OpenWhisk or
IronFunctions. Actually, in container world, there are already a lot of
projects doing the same thing. But again, I'm OpenStack developer, we are
running an OpenStack based public cloud, I don't want to mess things up to
introduce things which will probably introduce other things.


>
>
> Jsut for the info, I think this [0] is your previous ML thread...
> [0] http://lists.openstack.org/pipermail/openstack-dev/2017-
> May/116472.html
>
>
Thanks to find it out :)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [FaaS] Introduce a FaaS project

[Lingxian Kong]

On Mon, May 15, 2017 at 5:59 PM, Li Ma <skywalker.n...@gmail.com> wrote:

> Do you have submitted a proposal to create this project under
> OpenStack umbrella?
>

Yeah, as the first step: https://review.openstack.org/#/c/463953/


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

[openstack-dev] [FaaS] Introduce a FaaS project

[Lingxian Kong]

Yes, I am recreating the wheels :-)

I am sending this email not intend to say Qinling[1] project is a better
option than others as a project of function as a service, I just provide
another
possibility for developers/operators already in OpenStack world, and try my
luck to seek people who have the same interest in serverless area and
cooperate
together to make it more and more mature if possible, because I see
serverless
becomes more and more popular in current agile IT world but I don't see
there
is a good candidate in OpenStack ecosystem.

I remember I asked the question that if we have a FaaS available project in
OpenStack, what I got are something like: Picasso[2], OpenWhisk[3], etc, but
IMHO, none of them can be well integrated with OpenStack ecosystem. I don't
mean they are not good, on the contrary, they are good, especially OpenWhisk
which is already deployed and available in IBM Bluemix production. Picasso
is
only a very thin proxy layer to IronFunctions which is an open source
project
comes from Iron.io company who also has a commercial FaaS product.

However, there are several reasons make me create a new project:

- Maybe not many OpenStack operators/developers want to touch a project
  written in another programming language besides Python (and maybe Go? not
sure
  the result of TC resolution). The deployment/dependency management/code
  maintenance will bring much more overhead.

- I'd like to see a project which is using the similar
  components/infrastructure as most of the other OpenStack projects, e.g.
  keystone authentication, message queue(in order to receive notification
from
  Panko then trigger functions), database, oslo library, swift(for code
  package storage), etc. Of course, I could directly contribute and modify
  some existing project(e.g. Picasso) to satisfy these conditions, but I am
  afraid the time and effort it could take is exactly the same as if I
create
  a new one.

- I'd like to see a project with no vendor/platform lock-in. Most of the
FaaS
  projects are based on one specific container orchestration platform or
want
  to promote usage of its own commercial product. For me, it's always a good
  thing to have more technical options when evaluating a new service.

Qinling project is still at the very very early stage. I created it one
month ago
and work on it only in my spare time. But it works, you can see a basic
usage
introduction in README.rst and give it a try. A lot of things are still
missing, CLI, UT, devstack plugin, UI, etc.

Of course, you can ignore me (still appreciate you read here) if you think
it's really not necessary and stupid to create such a project in OpenStack,
or you can join me to discuss what we could do to improve it gradually and
provide a better option for a real function as a service to people in
OpenStack world.

[1]: https://github.com/LingxianKong/qinling
[2]: https://github.com/openstack/picasso
[3]: https://github.com/openwhisk/openwhisk

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

Re: [openstack-dev] [OpenStack][Mistral]A simple tool to discover and manage custom actions

[Lingxian Kong]

Hi, int32bit,

First, thanks very much for your work and share with us for what you did.

You are right about the lack of flexibility of current mistral action
registration process, in addition to your work, here are some of my
suggestions:

- I recommend you work with mistral team to figure out a way to improve
current tools/sync_db.py script, add the capability to manipulate actions
without reinstall mistral. I believe there are other people who are also
very interested in the enhancement.
- We (mistral team) are working on mistral-lib, a new library that will
define a base action class that all 3-rd party customized actions could
inherit, which aims to make action developer's life easier.

Thanks again for the email, feel free to jump in #openstack-mistral irc
channel for any further discussion.


Cheers,
Lingxian Kong (Larry)

On Tue, May 2, 2017 at 8:54 PM, int32bit <kryst...@gmail.com> wrote:

> Hi, All,
>
> As we know, Mistral allow developer  write a new custom action, but must
> reinstall Mistral service if it was installed in our system[1]. I think
> it's hardly acceptable for production environment.
>
> So I write a CLI tool used for automatically discovering & registering
> custom actions and no need modify any configuration and reinstall any
> service. In fact, it's completely independent with Mistral project.
>
> In addition, this project provide a CLI to manage custom actions, we can
> list all registered actions, and unregister any action if it doesn't need
> any more.
>
> For more detail, please see mistral-actions
> <https://github.com/int32bit/mistral-actions>.
>
> It work well on our environment but not sure if there is any potential
> risk. Thanks for any suggest and comment.
>
>
> [1] https://docs.openstack.org/developer/mistral/developer/
> creating_custom_action.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Release-job-failures][mistral] Release of openstack/python-mistralclient failed

[Lingxian Kong]

Thanks a lot!


Cheers,
Lingxian Kong (Larry)

On Tue, Apr 25, 2017 at 3:12 AM, Doug Hellmann <d...@doughellmann.com>
wrote:

> A recent patch in python-mistralclient added a release note that was
> poorly formatted, so it broke announcement job for the 3.1.0 release.
>
> I've proposed a fix for the note file in
> https://review.openstack.org/459341 and I've proposed the project-config
> changes to add the jobs to avoid allowing similar failures in the future
> in https://review.openstack.org/459343
>
> I also regenerated the announcement email by hand.
>
> Doug
>
> Excerpts from jenkins's message of 2017-04-24 13:41:24 +:
> > Build failed.
> >
> > - python-mistralclient-tarball http://logs.openstack.org/88/
> 888ad722abbd8308da91b15360a2e8d2fb582d65/release/python-
> mistralclient-tarball/e2b9206/ : SUCCESS in 4m 08s
> > - python-mistralclient-tarball-signing http://logs.openstack.org/88/
> 888ad722abbd8308da91b15360a2e8d2fb582d65/release/python-
> mistralclient-tarball-signing/2a5465a/ : SUCCESS in 52s
> > - python-mistralclient-pypi-both-upload http://logs.openstack.org/88/
> 888ad722abbd8308da91b15360a2e8d2fb582d65/release/python-
> mistralclient-pypi-both-upload/551cc60/ : SUCCESS in 26s
> > - python-mistralclient-announce-release http://logs.openstack.org/88/
> 888ad722abbd8308da91b15360a2e8d2fb582d65/release/python-
> mistralclient-announce-release/a578383/ : FAILURE in 3m 12s
> > - propose-python-mistralclient-update-constraints
> http://logs.openstack.org/88/888ad722abbd8308da91b15360a2e8
> d2fb582d65/release/propose-python-mistralclient-update-
> constraints/d356cb1/ : SUCCESS in 1m 01s
> > - python-mistralclient-docs-tags-only http://logs.openstack.org/88/
> 888ad722abbd8308da91b15360a2e8d2fb582d65/release/python-
> mistralclient-docs-tags-only/141c4cb/ : SUCCESS in 4m 04s
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [mistral] Using mistral to start a not-to-die task

[Lingxian Kong]

Yeah, as Bob said, cron-trigger is what you are looking for.

As our discussion on IRC, currently, Mistral doesn't support to execute
shell command directly, my suggestion is, you could consider using http
action (which is supproted by Mistral out of the box) or providing a host
(physical or virtual) to run 'ping' command and use ssh action in Mistral.


Cheers,
Lingxian Kong (Larry)

On Thu, Mar 23, 2017 at 1:16 PM, gongys2017 <gongys2...@aliyun.com> wrote:

> Hi mistral stackers,
>
> Tacker is using the mistral as its part of system. Now we have a
> requirement:
>
> tacker server registers an openstack as its NFVI, and needs to ping http-ping) the openstack's management IP,
> for example the keystone URL until tacker updates or delete the openstack
> NFVI.
>
> Can the mistral be asked to start a workflow which  contains  just such a
> kind of task:
> for ever running until extenal tells him to stop.
>
>
> Thanks
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][ironic] Kubernetes-based long running processes

[Lingxian Kong]

I thought somebody already asked in Mistral IRC channel, IMO, Mistral is a
good candidate in this case, TripleO[1] already use Mistral for running its
own tasks. For those who didn't know Mistral well, Mistral is a workflow
engine that can run you designed workflow in a stable, scalable way. For
your use case, the only thing needs to consider is if you need to provide
your customized actions (like what TripleO does). Feel free to jump in
#openstack-mistral if you have more questions.

[1]: https://github.com/openstack/tripleo-common


Cheers,
Lingxian Kong (Larry)

On Thu, Mar 16, 2017 at 11:28 AM, Taryma, Joanna <joanna.tar...@intel.com>
wrote:

> Hi all,
>
>
>
> There was an idea of using Kubernetes to handle long running processes for
> Ironic [0]. It could be useful for example for graphical and serial
> consoles or improving scalability (and possibly for other long-running
> processes in the future). Kubernetes would be used as a backend for running
> processes (as containers).
>
> However, the complexity of adding this to ironic would be a too laborious,
> considering the use case. At the PTG it was decided not to implement it
> within ironic, but in the future ironic may adopt such solution if it’s
> common.
>
>
>
> I’m reaching out to you to ask if you’re aware of any other use cases that
> could leverage such solution. If there’s a need for it in other project, it
> may be a good idea to implement this in some sort of a common place.
>
>
>
> Kind regards,
>
> Joanna
>
>
>
> [0] https://review.openstack.org/#/c/431605/
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [mistral] Proposing Michal Gershenzon to the core team

[Lingxian Kong]

+1, she indeed has been doing great contribution to Mistral, welcome,
Michal :-)


Cheers,
Lingxian Kong (Larry)

On Thu, Mar 2, 2017 at 5:47 AM, Renat Akhmerov <renat.akhme...@gmail.com>
wrote:

> Hi,
>
> Based on the stats of Michal Gershenzon in Ocata cycle I’d like to promote
> her to the core team.
> Michal works at Nokia CloudBand and being a CloudBand engineer she knows
> Mistral very well
> as a user and behind the scenes helped find a lot of bugs and make
> countless number of
> improvements, especially in performance.
>
> Overall, she is a deep thinker, cares about details, always has an unusual
> angle of view on any
> technical problem. She is one of a few people that I’m aware of who I
> could call a Mistral expert.
> She also participates in almost every community meeting in IRC.
>
> In Ocata she improved her statistics pretty significantly (e.g. ~60
> reviews although the cycle was
> very short) and is keeping up the good pace now. Also, Michal is
> officially planning to allocate
> more time for upstream development in Pike
>
> I believe Michal would be a great addition for the Mistral core team.
>
> Please let me know if you agree with that.
>
> Thanks
>
> [1] http://stackalytics.com/?module=mistral-group=
> ocata_id=michal-gershenzon
>
> Renat Akhmerov
> @Nokia
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] openstack jenkins failure

[Lingxian Kong]

Thanks for letting us know, Jeremy!


Cheers,
Lingxian Kong (Larry)

On Fri, Feb 24, 2017 at 4:43 AM, Jeremy Stanley <fu...@yuggoth.org> wrote:

> On 2017-02-23 06:23:53 + (+), Guo, Ruijing wrote:
> > There are lots of openstack Jenkins failure. Anyone from
> > infrastructure team look at the issue?
>
> Jobs fail all the time; can you be more specific?
>
> There was an issue earlier today where our distributed Ubuntu
> package mirror hadn't refreshed in a few days and then updated job
> node images ended up incorrectly expecting a newer set of qemu
> packages than we were providing on the mirrors. Perhaps this is what
> you saw?
>
> Those specific failures have been resolved by fixing the condition
> which had caused the mirror to cease updating, and a change is also
> in review now to keep situations like this from arising in the
> future.
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] FFE Request

[Lingxian Kong]

On Thu, Jan 26, 2017 at 9:37 PM, Rob Cresswell <robert.cressw...@outlook.com
> wrote:

> I'll put up Security Groups and Floating IPs once they start moving
> (maintaining huge patch chains is a waste of time)


​Huge +1!​



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

Re: [openstack-dev] [Horizon] [Performance] Gathering quota usage data in Horizon

[Lingxian Kong]

On Fri, Jan 27, 2017 at 12:28 AM, Rob Cresswell <
robert.cressw...@outlook.com> wrote:

> There's quite a lot to this. So, first off, quotas in horizon are not in
> great shape, and it should be one of our priorities next cycle to improve
> on this. As you've pointed out, it seems any check on quotas right now runs
> multiple serial API calls for everything that has quotas; I haven't checked
> this myself, but others have mentioned the same behaviour.
>
> I don't think anyone is actively working on improving quota behaviour, but
> in the past cycle these two efforts spring to mind:
> - https://blueprints.launchpad.net/horizon/+spec/make-quotas-great-again
> - https://review.openstack.org/#/c/334017/
>
> If there are people with time to work on this effort I'd be happy to
> review. Instances management, quotas, overview pages, Identity work are
> what I'd currently consider the top priorities for improvement.
>

​Thanks Rob for the information. We (Catalyst Cloud) are far more happy to
help with this effort​. I will take a look at the blueprint and check the
latest status of that work with the author.

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

Re: [openstack-dev] [Horizon] [Performance] Gathering quota usage data in Horizon

[Lingxian Kong]

Hi, guys,

Sorry for recalling this thread after 1 year, but we are currently
suffering from the poor performance issue for our public cloud.

As usage of our customers keeps growing, we are at a stage that should
seriously pay more attention to horizon performance problem, so Google took
me to this email after a lot of search.

Currently, when loading a page that may contain some buttons for
creating/allocating resource (e.g. 'Access & Security'), horizon will check
the quota usage first to see if a specific button should be disabled or
not, and the checkings just happen *in sequence*, which makes things even
worse.

What's more, the quota usage query in horizon is included in one
function[1], it will invoke Nova, Cinder, Neutron (perhaps more in future)
APIs to get usage of bunch of resources, rather than the resource that page
is rendering, which is another flaw IMHO. I know that this function call is
already put in cache, but most of our customers' pain just come from the
first click.

So, I have a few questions:

1. Does horizon support some config option that could disable quota check?
As a public cloud, it doesn't make much sense that usage should be limited,
and we have a monitoring tool that will increase quotas automatically when
customer's usage will hit the quota limit. So, getting rid of that check
will save our customers appreciable mass of waiting time.

2. Another option is to support get quota usage for specific resource
rather than all the resources, e.g. when loading floating ip tab, horizon
only get floating ip quota usage from Neutron, which has only 2 api calls.

3. I found this FFE[2] which is great (also replied), but splitting tabs is
not the end, more effort should be put into the performance improvement.

4. Some other trivial improvement like this:
https://review.openstack.org/425494

[1]: https://github.com/openstack/horizon/blob/master/
openstack_dashboard/usage/quotas.py#L396
[2]:
http://openstack.markmail.org/thread/ra3brm6voo4ouxtx#query:+page:1+mid:oata2tifthnhy5b7+state:results


Cheers,
Lingxian Kong (Larry)

On Wed, Dec 23, 2015 at 9:50 PM, Timur Sufiev <tsuf...@mirantis.com> wrote:

> Duncan,
>
> Thank you for the suggestion, will do.
>
> On Wed, 23 Dec 2015 at 10:55, Duncan Thomas <duncan.tho...@gmail.com>
> wrote:
>
>> On a cloud with a large number of tenants, this is going to involve a
>> large number of API calls. I'd suggest you put a spec into cinder to add an
>> API call for getting the totals straight out of the DB - it should be easy
>> enough to add.
>>
>> On 18 December 2015 at 20:35, Timur Sufiev <tsuf...@mirantis.com> wrote:
>>
>>> Matt,
>>>
>>> actually Ivan (Ivan, thanks a lot!) showed me the exact cinderclient
>>> call that I needed. Now I know how to retrieve Cinder quota usage info
>>> per-tenant, seems that to retrieve the same info cloud-wide I should sum up
>>> all the available tenant usages.
>>>
>>> With Cinder quota usages being sorted out, my next goal is Nova and
>>> Neutron. As for Neutron, there are plenty of quota-related calls I'm going
>>> to play with next week, perhaps there is something suitable for my use
>>> case. But as for Nova, I haven't found something similar to 'usage' of
>>> cinderclient call, so help from someone familiar with Nova is very
>>> appreciated :).
>>>
>>> [0] https://github.com/openstack/python-cinderclient/blob/ma
>>> ster/cinderclient/v2/quotas.py#L36
>>>
>>> On Fri, Dec 18, 2015 at 5:17 PM Matt Riedemann <
>>> mrie...@linux.vnet.ibm.com> wrote:
>>>
>>>>
>>>>
>>>> On 12/17/2015 2:40 PM, Ivan Kolodyazhny wrote:
>>>> > Hi Timur,
>>>> >
>>>> > Did you try this Cinder API [1]?  Here [2] is cinderclient output.
>>>> >
>>>> >
>>>> >
>>>> > [1]
>>>> > https://github.com/openstack/python-cinderclient/blob/master
>>>> /cinderclient/v2/quotas.py#L33
>>>> > [2] http://paste.openstack.org/show/482225/
>>>> >
>>>> > Regards,
>>>> > Ivan Kolodyazhny,
>>>> > http://blog.e0ne.info/
>>>> >
>>>> > On Thu, Dec 17, 2015 at 8:41 PM, Timur Sufiev <tsuf...@mirantis.com
>>>> > <mailto:tsuf...@mirantis.com>> wrote:
>>>> >
>>>> > Hello, folks!
>>>> >
>>>> > I'd like to initiate a discussion of the feature request I'm going
>>>> > to make on behalf of Horizon to every core OpenStack service which
>>>> > supports Quota feature, namely Cinder, Nova and Neutron.
>>&

Re: [openstack-dev] [horizon] FFE Request

[Lingxian Kong]

Hi, Rob,

First, thanks for your work!

What's your plan for the other two tabs (security group, floatingip)? I
could see the split is very helpful no matter from performance perspective
and both useful from end user's perspective.

BTW, a huge +1 for this FFE!




Cheers,
Lingxian Kong (Larry)

On Thu, Jan 26, 2017 at 9:01 AM, Adrian Turjak <adri...@catalyst.net.nz>
wrote:

> +1
>
> We very much need this as the performance of that panel is awful. This
> solves that problem while being a fairly minor code change which also
> provides much better UX.
>
>
> On 26/01/2017 8:07 AM, Rob Cresswell <robert.cressw...@outlook.com> wrote:
>
> o/
>
> I'd like to request an FFE on https://blueprints.
> launchpad.net/horizon/+spec/reorganise-access-and-security. This
> blueprint splits up the access and security tabs into 4 distinct panels.
> The first two patches are https://review.openstack.org/#/c/408247 and
> https://review.openstack.org/#/c/425345/
>
> It's low risk; no API layer changes, mostly just moving code around.
>
> Rob
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TC][Glance][Nova][TripleO][Heat][Mistral][Ironic][Murano] Glare

[Lingxian Kong]

On Thu, Jan 19, 2017 at 5:54 AM, Mikhail Fedosin <mfedo...@gmail.com> wrote:

> And here I want to ask the community - how exactly Glare may be useful in
> OpenStack? Glare was developed as a repository for all possible data types,
> and it has many possible applications. For example, it's a storage of vm
> images for Nova. Currently Glance is used for this, but Glare has much more
> features and this transition is easy to implement. Then it's a storage of
> Tosca templates. We were discussing integration with Heat and storing
> templates and environments in Glare, also it may be interesting for TripleO
> project. Mistral will store its workflows in Glare, it has already been
> decided. I'm not sure if Murano project is still alive, but they already
> use Glare 0.1 from Glance repo and it will be removed soon (in Pike afaik),
> so they have no other options except to start using Glare v1. Finally there
> were rumors about storing torrent files from Ironic.


​Seems Swift already could do such things.​


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

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Lingxian Kong]

On Tue, Jan 17, 2017 at 10:09 AM, Fox, Kevin M <kevin@pnnl.gov> wrote:

> As for operators, If the more common projects all started depending on it,
> it would be commonly deployed. Would the operators deploy Barbican just for
> Magnum? maybe not. maybe so. For Magnum, Ironic, and Sahara, more likely .
> Would they deploy it if Neutron and Keystone depended on it, yeah. they
> would. And then all the other projects would benefit from it being there,
> such as Magnum.


Agree.

The problem is, was one project created just for being used together with
other OpenStack projects or it could be used perfectly in standalone mode?
There are a lot of projects nowadays in OpenStack besides the several most
important ones (Nova, Cinder, Neutron, Keystone, Glance, etc.). Most new
projects will say they can be used separately without necessarily in
OpenStack deployment, the question is, what are the advantages of the
project over the existing solutions? If the operators could get more
benefit by deploying and maintaining a new service than using a
pre-existing one?

>From my perspective (maybe I'm wrong), many projects are struggling in
OpenStack world, and at the same time, they are not that competitive with
solutions outside OpenStack world.

Just my $0.002



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

Re: [openstack-dev] [FaaS] Function as a service in OpenStack

[Lingxian Kong]

On Wed, Dec 21, 2016 at 6:04 PM, Derek Schultz 
wrote:

> Hi all,
>
> We just released Picasso[1][2], an OpenStack API for Functions as a
> Service. I think it may be of particular interest to those in this thread,
> as it's based on IronFunctions, an open-source alternative to Lambda.
>
> The mission is to provide an API to run functions on OpenStack.
>

​Thanks very much for bringing Picasso here, I personally think it's very
import to have such a project in OpenStack ecosystem.


>
> Picasso is comprised of two main components:
>
>- Picasso API
>   - The Picasso API server uses Keystone authentication and
>   authorization through its middleware.
>- IronFunctions
>   - Picasso leverages the backend container engine provided by
>   IronFunctions[3], an open-source Serverless/FaaS platform based on 
> Docker.
>
> You can try out Picasso now on DevStack by following the quick start
> guide[4]. Let us know what you think!
>
> If you’re interested in contributing or just have any questions, please
> join us on Slack at open-iron.slack.com.
>

​Why not using an IRC channel?
​

>
> Regards,
> Derek
>
> [1] https://launchpad.net/picasso
>
> [2] https://launchpad.net/python-picassoclient
>
> [3] https://github.com/iron-io/functions
>
> [4] https://github.com/iron-io/picasso/blob/master/README.
> md#quick-start-guide
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Lingxian Kong]

On Wed, Dec 14, 2016 at 4:34 PM, Takashi Yamamoto 
wrote:

> hi,
>
> which driver are you using?
>

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

Re: [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Lingxian Kong]

Hi, Takashi,

Thanks for working on this project, we (Catalyst Cloud) also provide VPNaaS
in our OpenStack based public cloud, so maybe we can also provide help from
our side.


Cheers,
Lingxian Kong (Larry)

On Mon, Nov 28, 2016 at 5:50 PM, Takashi Yamamoto <yamam...@midokura.com>
wrote:

> On Wed, Nov 16, 2016 at 11:02 AM, Armando M. <arma...@gmail.com> wrote:
> > Hi
> >
> > As of today, the project neutron-vpnaas is no longer part of the neutron
> > governance. This was a decision reached after the project saw a dramatic
> > drop in active development over a prolonged period of time.
> >
> > What does this mean in practice?
> >
> > From a visibility point of view, release notes and documentation will no
> > longer appear on openstack.org as of Ocata going forward.
> > No more releases will be published by the neutron release team.
> > The neutron team will stop proposing fixes for the upstream CI, if not
> > solely on a voluntary basis (e.g. I still felt like proposing [2]).
> >
> > How does it affect you, the user or the deployer?
> >
> > You can continue to use vpnaas and its CLI via the python-neutronclient
> and
> > expect it to work with neutron up until the newton
> > release/python-neutronclient 6.0.0. After this point, if you want a
> release
> > that works for Ocata or newer, you need to proactively request a release
> > [5], and reach out to a member of the neutron release team [3] for
> approval.
> > Assuming that the vpnaas CI is green, you can expect to have a working
> > vpnaas system upon release of its package in the foreseeable future.
> > Outstanding bugs and new bug reports will be rejected on the basis of
> lack
> > of engineering resources interested in helping out in the typical
> OpenStack
> > review workflow.
> > Since we are freezing the development of the neutron CLI in favor of the
> > openstack unified client (OSC), the lack of a plan to make the VPN
> commands
> > available in the OSC CLI means that at some point in the future the
> neutron
> > client CLI support for vpnaas may be dropped (though I don't expect this
> to
> > happen any time soon).
> >
> > Can this be reversed?
> >
> > If you are interested in reversing this decision, now it is time to step
> up.
> > That said, we won't be reversing the decision for Ocata. There is quite a
> > curve to ramp up to make neutron-vpnaas worthy of being classified as a
> > neutron stadium project, and that means addressing all the gaps
> identified
> > in [6]. If you are interested, please reach out, and I will work with
> you to
> > add your account to [4], so that you can drive the neutron-vpnaas agenda
> > going forward.
> >
> > Please do not hesitate to reach out to ask questions and/or
> clarifications.
>
> hi,
>
> i'm interested in working on the project.
> well, at least on the parts which is used by networking-midonet.
>
> >
> > Cheers,
> > Armando
> >
> > [1] https://review.openstack.org/#/c/392010/
> > [2] https://review.openstack.org/#/c/397924/
> > [3] https://review.openstack.org/#/admin/groups/150,members
> > [4] https://review.openstack.org/#/admin/groups/502,members
> > [5] https://github.com/openstack/releases
> > [6]
> > http://specs.openstack.org/openstack/neutron-specs/specs/
> stadium/ocata/neutron-vpnaas.html
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap

[Lingxian Kong]

thanks very much for the update!


Cheers,
Lingxian Kong (Larry)

On Tue, Nov 8, 2016 at 12:36 PM, Michael Johnson <johnso...@gmail.com>
wrote:

> Ocata LBaaS retrospective and next steps recap
> --
>
> This session lightly touched on the work in the newton cycle, but
> primarily focused on planning for the Ocata release and the LBaaS spin
> out of neutron and merge into the octavia project [1].  Notes were
> captured on the etherpad [1].
>
> The focus of work for Ocata in neutron-lbaas and octavia will be on
> the spin out/merge and not new features.
>
> Work has started on merging neutron-lbaas into the octavia project
> with API sorting/pagination, quota support, keystone integration,
> neutron-lbaas driver shim, and documentation updates.  Work is still
> needed for policy support, the API shim to handle capability gaps
> (example: stats are by listener in octavia, but by load balancer in
> neturon-lbaas), neutron api proxy, a database migration script from
> the neutron database to the octavia database for existing non-octavia
> load balancers, and adding the "bug for bug" neutron-lbaas v2 API to
> the octavia API server.
>
> The room agreed that since we will have a shim/proxy in neutron for
> some time, updating the OpenStack client can be deferred to a future
> cycle.
>
> There is a lot of concern about Ocata being a short cycle and the
> amount of work to be done.  There is hope that additional resources
> will help out with this task to allow us to complete the spin
> out/merge for Ocata.
>
> We discussed the current state of the active/active topology patches
> and agreed that it is unlikely this will merge in Ocata.  There are a
> lot of open comments and work to do on the patches.  It appears that
> these patches may have been created against an old release and require
> significant updating.
>
> Finally there was a question about when octavia would implement
> metadata tags.  When we dug into the need for the tags we found that
> what was really wanted is a full implementation of the flavors
> framework [3] [4].  Some vendors expressed interest in finishing the
> flavors framework for Octavia.
>
> Thank you to everyone that participated in our design session and etherpad.
>
> Michael
>
> [1] https://specs.openstack.org/openstack/neutron-specs/specs/
> newton/kill-neutron-lbaas.html
> [2] https://etherpad.openstack.org/p/ocata-neutron-octavia-lbaas-session
> [3] https://specs.openstack.org/openstack/neutron-specs/specs/
> mitaka/neutron-flavor-framework-templates.html
> [4] https://specs.openstack.org/openstack/neutron-specs/specs/
> liberty/neutron-flavor-framework.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [mistral] Meeting Time

[Lingxian Kong]

Hi, Dougal,

Thanks for bringing this, already replied.


Cheers,
Lingxian Kong (Larry)

On Tue, Nov 8, 2016 at 5:20 AM, Dougal Matthews <dou...@redhat.com> wrote:

> Hi all,
>
> We want to make sure that the Mistral meeting time is as good as possible,
> so that everyone interested can attend. To do that, please add your
> name/nick and the times that suit you to this etherpad:
>
> https://etherpad.openstack.org/p/mistral-meeting-time
>
> If we are really lucky, we will find a time in that for everyone. if we
> are slightly lucky we will find two time slots that covers everyone and the
> meeting can alternate.
>
> We may find that the current time is best for everyone, but I wanted to
> make sure.
>
> Cheers,
> Dougal
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [mistral] Promoting Dougal Matthews to the core team

[Lingxian Kong]

+1 of course!


Cheers,
Lingxian Kong (Larry)

On Tue, Nov 8, 2016 at 6:09 PM, Renat Akhmerov <renat.akhme...@gmail.com>
wrote:

> Hi,
>
> I’d like to promote Dougal Matthews to the Mistral core team. [1] shows
> Dougal’s Mistral contribution summary for Newton cycle.
>
> Here are the reasons why I would like to see Dougal in the core team:
>
>- He reviews a lot and provides valuable comments, especially when it
>comes to discussing design of the new features
>- He sent 18 patches in Newton cycle which may not be a big number but
>it was his first full cycle in Mistral and I believe he can do more
>- He is one of the most active team members in general and in IRC
>specifically, always open for communication and easy to talk to
>- He is an active user of Mistral which is very important for me since
>he’s capable of providing valuable practical feedback on design, usability,
>reliability etc.
>- He seems to be very excited about working on Mistral
>
>
> Besides that I believe Dougal makes a good friendly atmosphere in our
> development team daily in our IRC channel and our weekly IRC meetings.
>
> Team, I would ask you to support me in this promotion.
>
> Thanks
>
> [1] http://stackalytics.com/?module=mistral-group_id=
> d0ugal=newton=marks
>
> Renat Akhmerov
> @Nokia
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [mistral] Team meeting minutes/log - 11/07/2016

[Lingxian Kong]

Hi, team,

I also added my time information in that etherpad, thanks for bringing that
into discussion.


Cheers,
Lingxian Kong (Larry)

On Tue, Nov 8, 2016 at 6:01 AM, Renat Akhmerov <renat.akhme...@gmail.com>
wrote:

> The minutes and log of the meeting we just had:
> http://eavesdrop.openstack.org/meetings/mistral/2016/
> mistral.2016-11-07-16.01.html
> http://eavesdrop.openstack.org/meetings/mistral/2016/
> mistral.2016-11-07-16.01.log.html
>
> Thanks for joining!
>
> Renat Akhmerov
> @Nokia
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [mistral] Ocata summit summary

[Lingxian Kong]

Thanks for sharing this, Renat!


Cheers,
Lingxian Kong (Larry)

On Thu, Nov 3, 2016 at 8:41 PM, Renat Akhmerov <renat.akhme...@gmail.com>
wrote:

> Hi,
>
> I’d like to share the summary of activities happened in Barcelona around
> Mistral.
>
> = Presentations =
>
> 1. *Building Self-healing Applications with Aodh, Zaqar and Mistral*
>
> https://www.openstack.org/videos/video/building-self-
> healing-applications-with-aodh-zaqar-and-mistral
>
> It gives pretty interesting info on how to use Mistral in conjunction with
> other technologies like Aodh (alarming system)
> and Zaqar to build something useful.
>
>
> 2. *Nokia: TOSCA & Mistral: Orchestrating End-to-End Telco Grade NFV*
>
> https://www.openstack.org/videos/video/nokia-tosca-and-
> mistral-orchestrating-end-to-end-telco-grade-nfv
>
> This is a quick introduction into Mistral (I believe from a slightly
> different angle than before) and the detailed description
> of one of the main Mistral use cases that we have at Nokia CloudBand.
>
> = Fishbowl =
>
> http://www.slideshare.net/DmitriZimine/mistral-and-stackstorm
>
> We had a very very cool fishbowl this time. Thanks a ton to Dmitri Zimine!
> Dmitri was talking about Mistral and StackStorm and his vision of the
> industry regarding workflow based automation,
> value of workflows and possible strategies on how StackStorm and Mistral
> can become more seamless in the future.
>
> = Design Sessions =
>
> https://etherpad.openstack.org/p/mistral-barcelona-summit-topics-2016
>
> Although we had only 2 design sessions (my fault, I should have asked
> more), we were able to discuss lots of technical
> topics during them and the contributors meetup that we had Friday
> afternoon.
>
> I won’t be repeating here everything what’s in the etherpad but
> summarizing it I would say that we’re now finally taking a
> course on making Mistral more consumable. For example, we have a bunch of
> plans on how to improve our documentation
> (better structure, more examples and cookbooks). We are also willing to
> fix our actions subsystem which is now not very
> mature, to be honest. Specifically, it applies to how we write actions and
> what’s available in Mistral code base to help with
> this, test coverage of OpenStack actions is now very basic and requires a
> more solid approach. We’re making big steps
> now towards it. Generally, I have to admit that actions is one of our
> biggest problems now because existing OpenStack
> actions often go out of sync with underlying APIs and a lot of new people
> start getting familiar with Mistral exactly by
> trying workflows with OpenStack actions, so those workflows often simply
> don’t work and that makes an impression that
> Mistral doesn’t work. Although the core Mistral functionality is now
> pretty robust and performant. We need to improve it
> asap (as a matter of fact, yesterday).
>
>
> Any feedback or comments on what we’re doing in Mistral are very welcome!
>
> Thanks
>
> Renat Akhmerov
> @Nokia
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [FaaS] Function as a service in OpenStack

[Lingxian Kong]

On Thu, Nov 3, 2016 at 10:44 AM, Zane Bitter  wrote:

> This is a really interesting space. There seems to be two main use cases
> for Lambda that are probably worth talking about separately:
>
> The first is for just Lambda alone. You can use it to provide some glue
> logic between the other AWS services, so you can trigger off various events
> (e.g. S3 notifications) and write a little bit of conditioning logic that
> transforms the data and dispatches it to other services (e.g. DynamoDB).
> This one is particularly interesting to me, and in fact we can support
> parts of this in OpenStack already[1] because Mistral's functionality is
> equivalent to something like SWS + parts of Lambda. (Specifically, Mistral
> can do the data dispatch easily enough, but any data transformation has to
> be done in YAQL, which is a pretty high bar compared to just writing some
> code in a language of your choosing.)
>

​There is still one thing missing in Mistral​ (maybe it should not be).
After receieving events from Aodh or Zaqar, what if user just wants to
trigger some scripts under his/her management, rather than just invoking
openstack services api? Although actions are pluggable in Mistral, but in
this case it's definitely not an easy thing as just writing an customized
action, unless Mistral could include such capatility in its scope which I
think it too heavy for Mistral to mange such things by itself. So, FaaS
will be the right answer in this case, and it will also be add-on part to
empower Mistral to do more things.


>
> The second one is Lambda + the API Gateway, which allows you to have web
> requests act as triggers, so that you can effectively treat it as a PaaS
> and build an entire web app by stringing together Lambda functions and the
> various other services (S3, DynamoDB, ). On the face of it this sounds
> to me like a gimmicky way of deploying an unmaintainable mess. Naturally
> this is the one receiving all of the attention, which shows how much I know
> :D


​I also don't think this one is attractive to me, Lambda is especially
powerful when it's used together with other AWS services(S3,
DynamoDB, Kinesis Streams, etc).
​​

>
> I definitely don't think we should try to reimplement this from scratch in
> OpenStack. IMHO if we're going to add FaaS capabilities we should re-use
> some existing project (like OpenWhisk), even if we have to write our own
> native API over the top of it.
>
> The things we'd really want it to do would be:
>
> * Authenticate against Keystone,
> * Provide Keystone credentials for the user-supplied functions it runs to
> access (probably using Keystone trusts), and
> * Connect to existing OpenStack sources of events, which hopefully means
> Zaqar queues
>
> Which sounds challenging to integrate with an existing standalone project,
> though still not as bad as writing an equivalent from scratch.
>
> TBH I think the appeal, at least for the FaaS-as-a-PaaS (aka #serverless)
> crowd, is going to be pretty limited until such time as we have an
> equivalent of DynamoDB in OpenStack. (i.e. no time soon, since the
> MagnetoDB project is goneburger.) The idea of FaaS is to make the unit of
> compute power that you're paying for (a) as fine-grained as possible, and
> (b) scalable to infinity. Swift provides the same thing for storage
> (Nova:FaaS::Cinder:Swift). What we don't have is the equivalent for a
> database, there's only Trove where you're paying for a VM-sized chunk at a
> minimum and scaling up in units of VM-sized chunks until you reach the
> limit of how many VMs can communicate with each other and still get any
> work done. Not many web apps can get by without a database, so that largely
> negates the purpose to my mind, since the database will likely both
> dominate costs at the low end and put the upper limit on scale at the high
> end.
>

​Yeah, I agree with you that more things are needed so that FaaS-like stuff
could be used appropriately and ideally, we can't get everything ready on
day 1, that's how we do things,  from simple to complex, isn't it?



>
> cheers,
> Zane.
>
> [1] https://www.openstack.org/videos/video/building-self-healing
> -applications-with-aodh-zaqar-and-mistral
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [FaaS] Function as a service in OpenStack

[Lingxian Kong]

On Thu, Nov 3, 2016 at 5:08 AM, Clint Byrum  wrote:

I don't have answers to these questions, but I'd ask:
>
> * Does OpenWhisk have a significant user base?
>
> * Do the goals of OpenWhisk run parallel to the goals of OpenStack?
>
> * Can any OpenStack operator deploy OpenWhisk and immediately begin
>   providing serverless to their users?
>

​Yeah, all good questions, I'm afraid only OpenWhisk guys could answer
that, and I also really hope OpenWhisk could be part of OpenStack and
provide more documentations, so people won't recreate the wheels any more.
​
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [FaaS] Function as a service in OpenStack

[Lingxian Kong]

Hi, all,

Recently when I was talking with some customers of our OpenStack based
public cloud, some of them are expecting to see a service similar to AWS
Lambda in OpenStack ecosystem (so such service could be invoked by Heat,
Mistral, Swift, etc.).

Coincidently, I happened to see an introduction of OpenWhisk project by IBM
guys in Barcelona Summit. The demo was great and I was much more exsited to
know it was opensourced, but after checking, I feels a little bit
frustrated, most of the core part of the code was written in Scala so it
sets a high bar for me (yeah, I'm using Python) to learn and understand.

So I came here to ask if there are people who are interested in serverless
area as me or have the same requirements as our customers? Does it deserve
a new project complies with OpenStack rules and conventions? Is there any
chance that people could join together for the implementation?

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

Re: [openstack-dev] [mistral] Don't use Scheduler to run actions

[Lingxian Kong]

Hi, Renat,

Thanks for raising it up!

Does that mean mistral-engine will do the RPC call directly to
mistral-executor after storing the calling information somewhere? I think a
flow chart would be better to explain current problem and your proposal,
and what's more, I personally think it deserves a spec since I see it as a
feature instead of a simple bug.


Cheers,
Lingxian Kong (Larry)

On Wed, Oct 5, 2016 at 11:14 PM, Renat Akhmerov <renat.akhme...@gmail.com>
wrote:

> Hi Team,
>
> I posted a bug [1] at Launchpad that is pretty important for many reasons.
> I tried to put all needed information into
> the bug description providing pros and cons of using Scheduler for running
> actions. I short, I’d like to remove
> Scheduler from the chain that leads to running an action on executor for
> performance reason (~30% difference
> on large workflows, from my experience). I decided to bring it up to a
> discussion here because I may be
> missing something and am very interested in your opinions. Please let me
> know if you have any additional
> arguments to those I provided in the bug.
>
> [1] https://bugs.launchpad.net/mistral/+bug/1630508
>
> Thanks
>
> Renat Akhmerov
> @Nokia
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release][mistral] mistral Newton RC1 available

[Lingxian Kong]

Thanks Dougal for reporting that, we are working on the issue.

Cheers,
Lingxian Kong (Larry)


On Fri, Sep 16, 2016 at 11:27 PM, Dougal Matthews <dou...@redhat.com> wrote:
>
>
> On 16 September 2016 at 00:06, Doug Hellmann <d...@doughellmann.com> wrote:
>>
>> Hello everyone,
>>
>> The release candidate for mistral for the end of the Newton cycle
>> is available!  You can find the RC1 source code tarballs at:
>>
>> https://tarballs.openstack.org/mistral/mistral-3.0.0.0rc1.tar.gz
>>
>> https://tarballs.openstack.org/mistral-dashboard/mistral-dashboard-3.0.0.0rc1.tar.gz
>>
>> Unless release-critical issues are found that warrant a release
>> candidate respin, this RC1 will be formally released as the final
>> Newton release on 6 October. You are therefore strongly
>> encouraged to test and validate this tarball!
>
>
> I believe we (TripleO) are hitting a release critical issue here:
> https://bugs.launchpad.net/mistral/+bug/1624284
>
> I have tagged the issue.
>
>
>> Alternatively, you can directly test the stable/newton release
>> branch at:
>>
>> http://git.openstack.org/cgit/openstack/mistral/log/?h=stable/newton
>>
>> If you find an issue that could be considered release-critical,
>> please file it at:
>>
>> https://bugs.launchpad.net/mistral/+filebug
>>
>> and tag it *newton-rc-potential* to bring it to the mistral release
>> crew's attention.
>>
>> Note that the "master" branch of mistral is now open for Ocata
>> development, and feature freeze restrictions no longer apply there!
>>
>> Thanks,
>> Doug
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [release][ptl] stable/newton branches

[Lingxian Kong]

Hi, Doug, Mistral didn't have a stable/newton branch, did we miss something?

I already sent msg in release team irc channel, ask here again in case
you didn't see that :-)

Cheers,
Lingxian Kong (Larry)


On Tue, Sep 20, 2016 at 7:06 AM, Doug Hellmann <d...@doughellmann.com> wrote:
> All of the cycle-with-milestone projects have tagged a first release
> candidate and had their stable/newton branches created.
>
> Most of the intermediary projects also have had their stable/newton
> branches created.
>
> If you have a project that has not yet had a branch created, and
> you are ready to have one, reply to this email thread with the
> deliverable names.
>
> Remember, we always create stable branches from tagged versions so
> we will use the most recently tagged version as the branch point.
> If you want the branch to include something that has been committed
> to master after that tag, we will need to tag again before branching.
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [mistral] Promoting Dawid Deja to core reviewers

[Lingxian Kong]

+1, good job, Dawid!

Regards!
---
Lingxian Kong


On Sat, Jul 30, 2016 at 10:59 PM, Elisha, Moshe (Nokia - IL)
<moshe.eli...@nokia.com> wrote:
> Hi,
>
> I am not a core reviewer but having met Dawid in person and working closely
> with him on some important bug fixes – I fully support the idea.
>
> From: Anastasia Kuznetsova <akuznets...@mirantis.com>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Date: Friday, 29 July 2016 at 15:53
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [mistral] Promoting Dawid Deja to core
> reviewers
>
> Renat,
>
> I fully support Dawid's promotion! Here is my +1 for Dawid.
>
> Dawid,
>
> I will be glad to see you in the Mistral core team.
>
> On Fri, Jul 29, 2016 at 2:39 PM, Renat Akhmerov <renat.akhme...@gmail.com>
> wrote:
>>
>> Hi,
>>
>> I’d like to promote Dawid Deja working at Intel (ddeja in IRC) to Mistral
>> core reviewers.
>>
>> The reasons why I want to see Dawid in the core team is that he provides
>> amazing, very thorough reviews.
>> Just by looking at a few of them I was able to make a conclusion that he
>> knows the system architecture very well
>> although he started contributing actively not so long ago. He always sees
>> things deeply, can examine a problem
>> from different angles, demonstrates solid technical background in general.
>> He is in top 5 reviewers now by a number
>> of reviews and the only one who still doesn’t have core status. He also
>> implemented several very important changes
>> during Newton cycle. Some of them were in progress for more than a year
>> (flexible RPC) but Dawid helped to knock
>> them down elegantly.
>>
>> Besides purely professional skills that I just mentioned I also want to
>> say that it’s a great pleasure to work with
>> Dawid. He’s a bright cheerful guy and a good team player.
>>
>> Dawid’s statistics is here:
>> http://stackalytics.com/?module=mistral-group=commits_id=dawid-deja-0
>>
>>
>> I’m hoping for your support in making this promotion.
>>
>> Thanks
>>
>> Renat Akhmerov
>> @Nokia
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Best regards,
> Anastasia Kuznetsova
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [octavia][upgrades] upgrade loadbalancer to new amphora image

[Lingxian Kong]

Hi guys, in case you are interested, here is a script that will do the
amphora upgrade automatically (ok, it's not totally automatic, need
two inputs).

https://github.com/LingxianKong/octavia-stuff/blob/master/utils/octavia-upgrade-vms.py

Regards!
---
Lingxian Kong


On Fri, Jul 1, 2016 at 4:53 AM, Doug Wiegley
<doug...@parksidesoftware.com> wrote:
>
>> On Jun 30, 2016, at 7:15 AM, Ihar Hrachyshka <ihrac...@redhat.com> wrote:
>>
>>>
>>> On 30 Jun 2016, at 01:16, Brandon Logan <brandon.lo...@rackspace.com> wrote:
>>>
>>> Hi Ihar, thanks for starting this discussion.  Comments in-line.
>>>
>>> After writing my comments in line, I might now realize that you're just
>>> talking about documenting  a way for a user to do this, and not have
>>> Octavia handle it at all.  If that's the case I apologize for my reading
>>> comprehension, but I'll keep my comments in case I'm wrong.  My brain is
>>> not working well today, sorry :(
>>
>> Right. All the mechanisms needed to apply the approach are already in place 
>> in both Octavia and Neutron as of Mitaka. The question is mostly about 
>> whether the team behind the project may endorse the alternative approach in 
>> addition to whatever is in the implementation in regards to failovers by 
>> giving space to describe it in the official docs. I don’t suggest that the 
>> approach is the sole documented, or that octavia team need to implement 
>> anything. [That said, it may be wise to look at providing some smart scripts 
>> on top of neutron/octavia API that would realize the approach without 
>> putting the burden of multiple API calls onto users.]
>
> I don’t have a problem documenting it, but I also wouldn’t personally want to 
> recommend it.
>
> We’re adding a layer of NAT, which has performance and HA implications of its 
> own.
>
> We’re adding FIPs, when the neutron advice for “simple nova-net like 
> deployment” is provider nets and linuxbridge, which don’t support them.
>
> Thanks,
> doug
>
>
>>
>>>
>>> Thanks,
>>> Brandon
>>>
>>> On Wed, 2016-06-29 at 18:14 +0200, Ihar Hrachyshka wrote:
>>>> Hi all,
>>>>
>>>> I was looking lately at upgrades for octavia images. This includes using 
>>>> new images for new loadbalancers, as well as for existing balancers.
>>>>
>>>> For the first problem, the amp_image_tag option that I added in Mitaka 
>>>> seems to do the job: all new balancers are created with the latest image 
>>>> that is tagged properly.
>>>>
>>>> As for balancers that already exist, the only way to get them use a new 
>>>> image is to trigger an instance failure, that should rebuild failed nova 
>>>> instance, using the new image. AFAIU the failover process is not currently 
>>>> automated, requiring from the user to set the corresponding port to DOWN 
>>>> and waiting for failover to be detected. I’ve heard there are plans to 
>>>> introduce a specific command to trigger a quick-failover, that would 
>>>> streamline the process and reduce the time needed for the process because 
>>>> the failover would be immediately detected and processed instead of 
>>>> waiting for keepalived failure mode to occur. Is it on the horizon? 
>>>> Patches to review?
>>>
>>> Not that I know of and with all the work slated for Newton, I'm 99% sure
>>> it won't be done in Newton.  Perhaps Ocata.
>>
>> I see. Do we maybe want to provide a smart script that would help to trigger 
>> a failover with neutron API? [detect the port id, set it to DOWN, …]
>>
>>>>
>>>> While the approach seems rather promising and may be applicable for some 
>>>> environments, I have several concerns about the failover approach that we 
>>>> may want to address.
>>>>
>>>> 1. HA assumption. The approach assumes there is another node running 
>>>> available to serve requests while instance is rebuilding. For non-HA 
>>>> amphoras, it’s not the case, meaning the image upgrade process has a 
>>>> significant downtime.
>>>>
>>>> 2. Even if we have HA, for the time of instance rebuilding, the balancer 
>>>> cluster is degraded to a single node.
>>>>
>>>> 3. (minor) during the upgrade phase, instances that belong to the same HA 
>>>> amphora may run different versions of the image.
>>>>
>>>> What’s the alternative?
>>

Re: [openstack-dev] [mistal] Mistral logo ideas?

[Lingxian Kong]

+1 to the mistral-tornado.png logo, looks amazing! Thanks!

Regards!
---
Lingxian Kong


On Tue, Jun 28, 2016 at 5:38 PM, Jason Rist <jr...@redhat.com> wrote:
> On 06/27/2016 06:57 AM, Dougal Matthews wrote:
>> On 27 June 2016 at 07:45, Renat Akhmerov <renat.akhme...@gmail.com> wrote:
>>
>> >
>> >> Ideally it would be nice to have something that matches the meaning of
>> > the
>> >> name. Maybe we can combine wind with one of the other ideas.
>> >>
>> >> I like the idea of the logo being a stylized wind turbine. Perhaps it
>> > could be
>> >> a turbine with a gust of wind. Then we can show that Mistral harnesses
>> > the
>> >> power of the wind :-)
>> >
>> > Yeah, I’m just wondering how it would look like :)
>> >
>> >
>> Yeah, for this idea we probably need somebody with artistic skills far
>> superior
>> to anything I could manage. We are getting quite a few good ideas now
>> anyway!
>>
>>
>> Renat Akhmerov
>> > @Nokia
>> >
>> >
>>
>
> Ever since I saw the blueprint for a mistral logo, I've been working on some 
> ideas.  I've presented a few to Dougal and Ryan, but I'm sharing widely here. 
>  I also did the one Michal came up with in Illustrator as well.  Please give 
> me some feedback!  Both of the ones I thought of are "wind" related.  I 
> thought about doing the ship before as well, but perhaps a little too war 
> related, and also obscure.
>
> Thanks,
> Jason
>
> P.S. you may recognize my name from the DLRN logo [1] and the TripleO Logo 
> [2].
>
> [1] 
> https://github.com/openstack-packages/DLRN/blob/master/doc/source/_images/DLRN.png
> [2] 
> https://github.com/dprince/tripleosphinx/blob/master/tripleosphinx/theme/tripleo/static/tripleo_owl.svg
>
> --
> Jason E. Rist
> Senior Software Engineer
> OpenStack User Interfaces
> Red Hat, Inc.
> openuc: +1.972.707.6408
> mobile: +1.720.256.3933
> Freenode: jrist
> github/twitter: knowncitizen
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [Mistral][Zaqar] Triggering Mistral workflows from Zaqar messages

[Lingxian Kong]

Hi, Zane, I think you must be interested in this:
https://review.openstack.org/#/c/308664/

Regards!
---
Lingxian Kong


On Fri, May 20, 2016 at 9:49 AM, Zane Bitter <zbit...@redhat.com> wrote:
> On 19/05/16 04:20, Thomas Herve wrote:
>>
>> On Wed, May 18, 2016 at 8:49 PM, Zane Bitter <zbit...@redhat.com> wrote:
>>>
>>> I've been lobbying the Mistral developers for $SUBJECT since, basically,
>>> forever.[1][2][3] I like to think after a couple of years I succeeded in
>>> changing their view on it from "crazy" to merely "unrealistic".[4] In the
>>> last few months I've had a couple of realisations though:
>>>
>>> 1) The 'pull' model I've been suggesting is the wrong one,
>>> architecturally
>>> speaking. It's asking Mistral to do too much to poll Zaqar queues.
>>> 2) A 'push' model is the correct architecture and it already exists in
>>> the
>>> form of Zaqar's Notifications, which suddenly makes this goal look very
>>> realistic indeed.
>>>
>>> I've posted a Zaqar spec for this here:
>>>
>>> https://review.openstack.org/#/c/318202/
>>
>>
>> Commented. I certainly need some more time to think about it.
>
>
> Thanks, I updated the spec based on your comments.
>
>>> Not being super familiar with either project myself, I think this needs
>>> close scrutiny from Mistral developers as well as Zaqar developers to
>>> make
>>> sure I haven't got any of the details wrong. I'd also welcome any
>>> volunteers
>>> interested in implementing this :)
>>>
>>>
>>> One more long-term thing that I did *not* mention in the spec: there are
>>> both Zaqar notifications and Mistral actions for sending email and
>>> hitting
>>> webhooks. These are two of the hardest things for a cloud operator to
>>> secure. It would be highly advantageous if there were only _one_ place in
>>> OpenStack where these were implemented. Either project would potentially
>>> work - Zaqar notifications could call a simple, operator defined workflow
>>> behind the scenes for email/webhook notifications; alternatively the
>>> Mistral
>>> email/webhook actions could drop a message on a Zaqar queue connected to
>>> a
>>> notification - although the former sounds easier to me. (And of course
>>> clouds with only one of the services available could fall back to the
>>> current plugins.) Something to think about for the future...
>>
>>
>> And you're forgetting about Aodh alarm notifications, which are
>> webhooks as well.
>
>
> Yeah, those just need to go away :) Aodh can already post the notifications
> to Zaqar instead, and hopefully we'll be able to migrate everything to that
> method over time.
>
>> Unfortunately, I think none of them do a
>> particularly great job in terms of robustness and security.
>
>
> Agree. The best you can do is still middling, and we're not there yet.
>
>> I
>> suggested moving away from doing webhook in Zaqar to Flavio in the
>> past, and I think he responded that he thought it was part of the core
>> functionality. It's hard to delegate such operations and create a
>> dependency on another project. Maybe we can start by creating some
>> library code.
>
>
> I guess that's a start, but if I were running a large public cloud I'd
> probably want to isolate this on its own network surrounded by some pretty
> custom firewalls. A library doesn't really help make that easier.
>
> cheers,
> Zane.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [mistral] Promoting Hardik Parekh to core reviewers

[Lingxian Kong]

+1 to Hardik :-)
Regards!
---
Lingxian Kong


On Tue, May 10, 2016 at 8:49 PM, Renat Akhmerov
<renat.akhme...@gmail.com> wrote:
> I’d like to promote Hardik Parekh to Mistral core reviewers.
>
> He was #1 by number of commits and #3 by number of reviews in Mitaka cycle
> and I think he deserved it. His statistics for Mitaka is at [1].
>
> Please vote.
>
> [1]
> http://stackalytics.com/?release=mitaka=mistral-group=marks_id=hardik-parekh047
>
> Renat Akhmerov
> @Nokia
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [octavia] amphora flavour and load balancer topology

[Lingxian Kong]

On Tue, May 3, 2016 at 10:30 AM, Michael Johnson  wrote:
> Hi Lingxian,
>
> On #2, we would like to enable neutron flavors to support the
> selection of topology.  For example, "bronze" flavor may be
> standalone, "silver" would be active/standby.  However, that
> capability is not yet implemented.  Feel free to take that on if you
> have the cycles... grin.

:-)

Yeah, using neutron flavour can solve the problem to some extent.
According to https://review.openstack.org/#/c/310667/(maybe you
already have some discussion in Summit), octavia will be standalone
service in future, a long term roadmap, we should support this
capability with or without Neutron. I am willing to do some PoC and
contribute that to upstream. Thanks for the suggestion.

>
> Michael

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

[openstack-dev] [octavia] amphora flavour and load balancer topology

[Lingxian Kong]

Hi, octavia guys,

Recently, We have been thinking about deploying octavia into
production (pre-production first in our case). Here are some
questions/concerns that need your suggestions and feekback.

1. Octavia will use a default instance flavour, which is
pre-configured, to create amphorae. Do you have any suggestion about
how to choose the appropriate amphora flavor? or did someone have the
load balancer performance test with different amphora flavors? It's so
important because we need to charge users according to the flavor.

2. Currently, Octavia support 2 topologies for load balancer,
SINGLE/ACTIVE-STANDBY, which is also configured by deployer. Is there
any possibility for the users to decide which one to use? e.g. adding
a param in creating load balancer. I believe it's different SLA for
the 2 topologies, some users can afford the failure when using SINGLE
mode, just because they want to be charged less.

Regards!
---
Lingxian Kong

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

Re: [openstack-dev] [mistral] Bi-weekly team meetings

[Lingxian Kong]

seems like only this one suits for me(UTC+12).

* Tue, Web, Thu 5.00 UTC at [#openstack-meeting, #openstack-meeting-alt]

On Mon, Apr 4, 2016 at 9:14 PM, Renat Akhmerov <renat.akhme...@gmail.com> wrote:
> Hi,
>
> Our team meeting time slot (Mondays 16.00 UTC) doesn’t work for lots of team
> members well anymore. The issue is that we have team members from completely
> time zones.
>
> So we came up with an idea of having bi-weekly meetings similar to how, for
> example, Kolla team does [1]. We can decide that on odd weeks we use a time
> slot convenient for folks in Europe/Asia and on even weeks we make it more
> convenient for folks in North America.
>
> Below are the options we see
>
> Europe/Asia, odd weeks
>
> * Mon 16.00 UTC at #openstack-meeting (current time slot)
> * Mon 15.00 UTC at #openstack-meeting-3
>
> North America, even weeks
>
> * Tue 17.00 UTC at #openstack-meeting-4
> * Tue, Web, Thu 5.00 UTC at [#openstack-meeting, #openstack-meeting-alt]
>
> Please share your thoughts.
>
> [1] https://wiki.openstack.org/wiki/Meetings/Kolla
>
> Renat Akhmerov
> @Nokia
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards!
---
Lingxian Kong

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

[openstack-dev] [Mistral] Mitaka RC2 available

[Lingxian Kong]

Hi, OpenStackers:

Due to release-critical issues spotted in Mistral during RC1 testing,
a new release candidate was created for Mitaka. You can find the RC2
source code tarballs at:

https://tarballs.openstack.org/mistral/mistral-2.0.0.0rc2.tar.gz

Unless new release-critical issues are found that warrant a
last-minute release candidate respin, this tarball will be formally
released as the final "Mitaka" version on April 7th. You are therefore
strongly encouraged to test and validate this tarball !

Alternatively, you can directly test the mitaka release branches at:

http://git.openstack.org/cgit/openstack/mistral/log/?h=stable/mitaka

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/mistral/+filebug

and tag it *mitaka-rc-potential* to bring it to the Mistral release
crew's attention.

Thanks for all the effort of Mistral team members!

Cheers!

-- 
Regards!
---
Lingxian Kong

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

Re: [openstack-dev] [lbaas] [octavia] Proposing Bharath Munirajulu as Octavia Core

[Lingxian Kong]

not core reviewer, but wanna give my +1

On Thu, Mar 31, 2016 at 9:56 AM, Michael Johnson <johnso...@gmail.com> wrote:
> I would like to nominate Bharath Munirajulu (bharathm) as a OpenStack
> Octavia core reviewer.
> His contributions [1] are in line with other cores and he has been an
> active member of our community.  I have been impressed with the
> insight and quality of his reviews.
>
> Current Octavia cores, please vote by replying to this e-mail.
>
> Michael
>
>
> [1] http://stackalytics.com/report/contribution/octavia/90
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Regards!
---
Lingxian Kong

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

Re: [openstack-dev] [TaskFlow] TaskFlow persistence

[Lingxian Kong]

;>>   Thanks,
>>>
>>>   Josh
>>>
>>>
>>>   Michał Dulko wrote:
>>>
>>>   On 01/26/2016 10:23 AM, pn kk wrote:
>>>
>>>   Hi,
>>>
>>>   I use taskflow for job management and now
>>> trying to
>>>  persist
>>>   the state
>>>   of flows/tasks in mysql to recover incase
>>> of
>>>  process crashes.
>>>
>>>   I could see the state and the task results
>>> stored
>>>  in the
>>>   database.
>>>
>>>   Now I am looking for some way to store the
>>> input
>>>  parameters
>>>   of the tasks.
>>>
>>>   Please share your inputs to achieve this.
>>>
>>>   -Thanks
>>>
>>>   I've played with that some time ago and if I
>>> recall
>>>  correctly input
>>>   parameters should be available in the flow's
>>> storage, which
>>>   means these
>>>   are also saved to the DB. Take a look on
>>>  resume_workflows method
>>>   on my
>>>   old PoC [1] (hopefully TaskFlow haven't
>>> changed much
>>>  since then).
>>>
>>>   [1]
>>>
>>> https://review.openstack.org/#/c/152200/4/cinder/scheduler/manager.py
>>>
>>>
>>>
>>>
>>> __
>>>   OpenStack Development Mailing List (not for
>>> usage
>>>  questions)
>>>   Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>
>>> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>>>
>>>
>>> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>>>
>>>
>>> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>
>>>
>>> __
>>>   OpenStack Development Mailing List (not for usage
>>> questions)
>>>   Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>
>>> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>>>
>>>
>>> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>>>
>>>
>>> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>
>>> __
>>>  OpenStack Development Mailing List (not for usage
>>> questions)
>>>  Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>
>>> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>>>
>>>
>>> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>
>>> __
>>>  OpenStack Development Mailing List (not for usage questions)
>>>  Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>
>>> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>>>
>>>
>>> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>
>>> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>
>>> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards!
---
Lingxian Kong

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

Re: [openstack-dev] [release][all][ptl] preparing to create stable/mitaka branches for libraries

[Lingxian Kong]

Hi, Doug, python-mistralclient is missing, too.

openstack/python-mistralclient 2.0.0

On Thu, Mar 10, 2016 at 9:09 PM, Qi Ming Teng <teng...@cn.ibm.com> wrote:
> Hi,
>
> Looks like the python-senlinclient is missing from the list:
>
> openstack/python-senlinclient 0.4.0
>
> 0.4.0 will be its stable branch. Thanks.
>
> Regards,
> - Qiming
>
> Doug Hellmann ---2016-03-10 01:32:31---It's time to start opening the stable
> branches for libraries. I've prepared a list of repositories a
>
> From: Doug Hellmann <d...@doughellmann.com>
> To: openstack-dev <openstack-dev@lists.openstack.org>
> Date: 2016-03-10 01:32
> Subject: [openstack-dev] [release][all][ptl] preparing to create
> stable/mitaka branches for libraries
>
> 
>
>
>
> It's time to start opening the stable branches for libraries. I've
> prepared a list of repositories and the proposed versions from which
> we will create stable/mitaka branches, and need each team to sign off on
> the versions. If you know you intend to release a bug fix version in
> the next couple of days, we can wait to avoid having to backport
> patches, but otherwise we should go ahead and create the branches.
>
> I will process each repository as I hear from the owning team.
>
> openstack/ceilometermiddleware 0.4.0
> openstack/django_openstack_auth 2.2.0
> openstack/glance_store 0.13.0
> openstack/ironic-lib 1.1.0
> openstack/keystoneauth 2.3.0
> openstack/keystonemiddleware 4.3.0
> openstack/os-brick 1.1.0
> openstack/os-client-config 1.16.0
> openstack/pycadf 2.1.0
> openstack/python-barbicanclient 4.0.0
> openstack/python-brick-cinderclient-ext 0.1.0
> openstack/python-ceilometerclient 2.3.0
> openstack/python-cinderclient 1.6.0
> openstack/cliff 2.0.0
> openstack/python-designateclient 2.0.0
> openstack/python-glanceclient 2.0.0
> openstack/python-heatclient 1.0.0
> openstack/python-ironic-inspector-client 1.5.0
> openstack/python-ironicclient 1.2.0
> openstack/python-keystoneclient 2.3.1
> openstack/python-manilaclient 1.8.0
> openstack/python-neutronclient 4.1.1
> openstack/python-novaclient 3.3.0
> openstack/python-saharaclient 0.13.0
> openstack/python-swiftclient 3.0.0
> openstack/python-troveclient 2.1.0
> openstack/python-zaqarclient 1.0.0
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards!
---
Lingxian Kong

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

Re: [openstack-dev] [mistral] Team meeting - 02/01/2016

[Lingxian Kong]

Hi, guys,

It's hardly for me to attend the meeting due to the inconvenient time for
me. In M-3, I want to see resource sharing feature(particularly for
workflow first) landed and support UUID in URL and mistralclient, which I
have been working on currently.

Hope you could consider that when you make plans for M-3.

On Mon, Feb 1, 2016 at 8:33 PM, Renat Akhmerov <rakhme...@mirantis.com>
wrote:

> Hi,
>
> This is a reminder about a team meeting that we’ll have today at 16.00 UTC.
>
> Agenda:
>
>- Review action items
>- Current status (progress, issues, roadblocks, further plans)
>- Review M-3 BPs and bugs
>- Open discussion
>
>
>
>
> Renat Akhmerov
> @ Mirantis Inc.
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [mistral] Promoting Anastasia Kuznetsova to core reviewers

[Lingxian Kong]

+1 from me, welcome Anastasia!

On Fri, Jan 29, 2016 at 9:00 PM, Igor Marnat <imar...@mirantis.com> wrote:

> Folks,
> I'm not a core reviewer, but if I was, I'd definitely vote with +1.
>
> Good job, Anastasia! Keep going!
>
> Regards,
> Igor Marnat
>
> On Fri, Jan 29, 2016 at 10:23 AM, Elisha, Moshe (Nokia - IL) <
> moshe.eli...@nokia.com> wrote:
>
>> A very big +1
>> 
>> From: Renat Akhmerov [rakhme...@mirantis.com]
>> Sent: Friday, January 29, 2016 8:13 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: [openstack-dev] [mistral] Promoting Anastasia Kuznetsova to
>> core   reviewers
>>
>> Team,
>>
>> I’d like to promote Anastasia Kuznetsova to the core team. What she’s
>> been doing for 2 years is hard to overestimate. She’s done a huge amount of
>> work reviewing code, bugfixing and participating in public discussions
>> including our IRC channel #openstack-mistral. She is very reliable,
>> diligent and consistent about her work.
>>
>> Please vote.
>>
>> Renat Akhmerov
>> @ Mirantis Inc.
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [mistral] Team meeting minutes/log - 01/25/2016

[Lingxian Kong]

Hi, guys,

I'm afraid our weekly meeting time is not suitable for me any longer, my
time zone is NZDT(UTC+12), it is 5:00AM, too early in the morning :-(

On Tue, Jan 26, 2016 at 5:42 AM, Renat Akhmerov <rakhme...@mirantis.com>
wrote:

> Thanks for joining our meeting today.
>
> Here’s the links to the meeting minutes and log:
>
>-
>
> http://eavesdrop.openstack.org/meetings/mistral/2016/mistral.2016-01-25-16.00.html
>-
>
> http://eavesdrop.openstack.org/meetings/mistral/2016/mistral.2016-01-25-16.00.log.html
>
>
> Renat Akhmerov
> @ Mirantis Inc.
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [release] Release countdown for week R-11, Jan 18-22, Mitaka-2 milestone

[Lingxian Kong]

Thanks Doug for letting us know that!

On Wed, Jan 20, 2016 at 6:53 AM, Doug Hellmann <d...@doughellmann.com> wrote:
> Excerpts from Thierry Carrez's message of 2016-01-19 09:48:19 +0100:
>> Kyle Mestery wrote:
>> > One question I have is, what should the version for projects be? For
>> > example, for Neutron, M1 was set to 8.0.0.0b1. Should the M2 Neutron
>> > milestone be 8.0.0.0c1? Or 8.0.0.0b2?
>>
>> Good question! It should be X.0.0.0b2, so 8.0.0.0b2 for Neutron.
>> Cheers!
>>
>
> Right, the "b" means "beta" not just "after a". So we'll have a second
> beta, designated by 0b2.
>
> Another question that came up related to adding the milestone tags was
> whether to replace the old 0b1 tag info in the releases repository or to
> add the new one. Please add a new section for 0b2 tags in the
> appropriate deliverable file(s). We want to preserve the full history
> of the tags for documentation.
>
> Thanks,
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Regards!
---
Lingxian Kong

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

Re: [openstack-dev] [mistral] how to split mistral log files

[Lingxian Kong]

Hi, Tomer,

If you really want Mistral services to be running on different
processes or different servers, I recommend you use different config
file respectively, log file path can be configured differently, which
can achieve what you said.

On Tue, Jan 19, 2016 at 5:19 AM, SHTILMAN, Tomer (Tomer)
<tomer.shtil...@nokia.com> wrote:
>
>
> Hi All
>
> I have three linux service file for mistral api, engine and executor
>
> All of them running with different param in the “server” (api/
>
> E.g api is
>
> /usr/bin/mistral-server --config-file=/etc/mistral/mistral.conf --server=api
>
>
>
> All of the logs goes to /var/log/mistral/mistral-server.log
>
>
>
> I would like to split them into three different logs , without changing the
> service files themselves
>
> I thought of changing
> https://github.com/openstack/mistral/blob/master/setup.cfg
>
> And creating three different console scripts
>
> console_scripts =
>
> mistral-engine = mistral.cmd.launch:main
>
> mistral-api = mistral.cmd.launch:main
>
> mistral-executor = mistral.cmd.launch:main
>
> mistral-db-manage = mistral.db.sqlalchemy.migration.cli:main
>
>
>
> will be happy to get your inputs/thoughts
>
> Thanks
>
> Tomer
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards!
---
Lingxian Kong

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

Re: [openstack-dev] [Openstack] [celery][taskflow] Reg. celery and task-flow

[Lingxian Kong]

s into tasks
>>> and execute
>>> them.
>>>
>>>  From celery wiki, it also does almost similar behaviour.
>>>
>>> I guess in most of openstack components taskflow is widely
>>> used.
>>> Any places where its being replaced with celery ??
>>>
>>> Celery: https://wiki.openstack.org/wiki/Celery
>>> Distributed:
>>> https://wiki.openstack.org/wiki/DistributedTaskManagement
>>> TaskFlow: https://wiki.openstack.org/wiki/TaskFlow
>>>
>>> Thanks
>>> Eswar
>>>
>>>
>>> __
>>>
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>>>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>> ___
>>> Mailing list:
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>> Post to : openst...@lists.openstack.org
>>> <mailto:openst...@lists.openstack.org>
>>> Unsubscribe :
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>
>>>
>>> ___
>>> Mailing list:
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>> Post to : openst...@lists.openstack.org
>>> <mailto:openst...@lists.openstack.org>
>>> Unsubscribe :
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>
>>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards!
---
Lingxian Kong

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

Re: [openstack-dev] [mistral] [murano] [yaql] An online YAQL evaluator [was RE: [mistral] [murano] An online YAQL evaluator]

[Lingxian Kong]

Hi, Moshe,

Really amazing work! Thanks for the efforts from you guys!

On Wed, Dec 23, 2015 at 1:06 AM, ELISHA, Moshe (Moshe)
<moshe.eli...@alcatel-lucent.com> wrote:
> Hi all,
>
>
>
> Thank you for the kind words.
>
> Just wanted to let you know that yaqluator[1] was updated and now supports
> YAQL 1.0.2.
>
> There is also a checkbox there to work in “Legacy Mode”.
>
>
>
> Hope you will find it useful.
>
>
>
> [1] http://yaqluator.com/
>
>
>
>
>
> From: Renat Akhmerov [mailto:rakhme...@mirantis.com]
> Sent: Friday, August 14, 2015 11:51 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [mistral] [murano] An online YAQL evaluator
>
>
>
> I just read this thread so decided to add my 2 cents into the collection of
> opinions.
>
>
>
> Guys, I tried it out a couple of weeks ago (was told about it by one of my
> colleagues). This is really incredible! Especially given that you completed
> it in 24 hours :) I think as YAQL attracts more and more users it will be
> very handy tool. I am actually for improving it further.
>
>
>
> Thanks a lot! Looking forward to switch to yaql 1.0!
>
>
>
> Renat Akhmerov
>
> @ Mirantis Inc.
>
>
>
>
>
>
>
> On 05 Aug 2015, at 04:09, Stan Lagun <sla...@mirantis.com> wrote:
>
>
>
> Dmitry,
>
>
>
> yaql 1.0 has both str() and len() and much much more so there is no need to
> support them explicitly since Mistral is going to switch to yaql 1.0 and
> yaqluator.com is going to do the same
>
>
> Sincerely yours,
> Stan Lagun
> Principal Software Engineer @ Mirantis
>
>
>
>
> On Tue, Aug 4, 2015 at 8:55 PM, Dmitri Zimine <dzim...@stackstorm.com>
> wrote:
>
> Awesome! Really.
>
>
>
> Thank you folks for doing this.
>
>
>
> I am so much looking forward to moving it to 1.0 with more built-in
> functions and more power to extend it...
>
>
>
> Note that Mistral has a few extensions, like `str`, `len`, which are not in
> the scope of evaluator.
>
>
>
> DZ>
>
>
>
>
>
> On Aug 2, 2015, at 12:44 PM, Stan Lagun <sla...@mirantis.com> wrote:
>
>
>
> Guys, this is awesome!!!
>
>
>
> Happy to see yaql gets attention. One more initiative that you may find
> interesting is https://review.openstack.org/#/c/159905/
>
> This is an attempt to port yaql 1.0 from Python to JS so that the same can
> be done in browser
>
>
> Sincerely yours,
> Stan Lagun
> Principal Software Engineer @ Mirantis
>
>
>
>
> On Sun, Aug 2, 2015 at 5:30 PM, Nikolay Makhotkin <nmakhot...@mirantis.com>
> wrote:
>
> Hi guys!
>
>
>
> That's awesome! It is very useful for all us!
>
>
>
> --
>
> Best Regards,
>
> Nikolay
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards!
---
Lingxian Kong

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

Re: [openstack-dev] [all] using reno for release note management

[Lingxian Kong]

On Wed, Dec 9, 2015 at 3:33 AM, Emilien Macchi <emil...@redhat.com> wrote:

> This morning the Puppet OpenStack had the weekly meeting [1] and we
> discussed about using reno [2] for release note management.
>
> We saw three possibilities:
>
> 1/ we use reno and enforce each contributions (bugfix, feature, etc) to
> also edit a release note YAML file
> 2/ we use reno and the release note YAML file can be updated later (by
> the contributor or someone else)
>

This option is also how we use Reno in Mistral project, since it doesn't
make much sense we write something for all the code changes merged into the
project. I only recommend contributors to submit a releatenote file if the
bugfix is really so critical that we want deployers or users to know, or
it's a feature we want to share, or the change affects upgrade... etc. It's
better that contributors could submit another patch which depends on the
code changes.

3/ we don't use reno and continue to manually write release notes
>
> The solution 3/ is definitely not in our scope and we are willing to use
> reno. Though we are looking for a way to switch using it.
>
> Some people in our group shared some feedback, and ideas. Feel free to
> comment inline:
>
> * Having a YAML file for one feature/bugfix/... sounds heavy.
> * We have 23 repositories (modules) - we will probably start using reno
> for one or two modules, and see how it works.
> * We will apply 2/ with the goal to go 1/ one day. We think directly
> doing 1/ will have the risk to frustrate our group since not anyone is
> familiar with releases. Giving -1 to a good patch just because it does
> not have a release note update is not something we want now. We need to
> educate people at using it, that's why I think we might go 2/.
> * Using reno will spread the release note management to our group,
> instead of one release manager taking care of that.
>
> Feel free to have more feedback or comment inline, we are really willing
> to suggestions.
>
> Thanks!
>
> [1]
> https://wiki.openstack.org/wiki/Meetings/PuppetOpenStack#Previous_meetings
> (2] http://docs.openstack.org/developer/reno/
> --
> Emilien Macchi
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [mistral] Notifier about changes in the dsvm gates structure

[Lingxian Kong]

Hi, Anastasia,

First, thanks for writing down this, I can see that the way we do now
may really make things unstable and hard to debug the Jenkins
failures. I 100% agree with you about separating gate tests between
Mistral repo and python-mistralclient repo, as a result, they won't
interfere with each other when a new patch submitted.

On Tue, Nov 17, 2015 at 10:30 PM, Anastasia Kuznetsova
<akuznets...@mirantis.com> wrote:
> Hello Everyone,
>
> This is a notifier about the fact that Mistral team is on the way of
> refactoring of current Jenkins dsvm gates infrastructure.
> The final goal is to have voting dsvm gates which will run on every commit
> to mistral and mistralclient repositories.
>
> What we have now:
> - mistral repository:
> gate-mistral-devstack-dsvm job that installs mistral from commit and
> python-mistralclient from master,
> it runs both suite of tests on every commit: API tests from mistral
> repository and CLI tests from python-mistralclient repository;
> - mistralclient repository:
> gate-mistral-devstack-dsvm job that installs python-mistralclient from
> commit and mistral from master,
> it runs suite of CLI tests from python-mistralclient repository.
>
> As you can see, there is only job template for both repositories.
>
> What we will have (or what other projects have now):
> - mistral repository:
> gate-mistral-devstack-dsvm job that will install mistral from commit and
> latest released python-mistralclient
> (version will be taken according requirements), it will run only API tests
> from mistral repository.
> - mistralclient repository:
> gate-mistralclient-devstack-dsvm job that will install python-mistralclient
> from commit and mistral from master,
> it will run suite of CLI tests from python-mistralclient repository.
>
> As a result, we will have two separate job templates, in each of them we
> will run its own suite of tests.
>
> I've created appropriate blueprint for these changes
> mistral-making-dsvm-gates-voting and
> I am going to start work on its implementation.
>
>
> --
> Best regards,
> Anastasia Kuznetsova
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards!
---
Lingxian Kong

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

Re: [openstack-dev] [release] new change management tools and processes for stable/liberty and mitaka

[Lingxian Kong]

On Wed, Nov 4, 2015 at 3:46 AM, Doug Hellmann <d...@doughellmann.com> wrote:
> 1. We need one patch to the master branch of the project to add the
>instructions for publishing the notes as part of the project
>sphinx documentation build.  An example patch for Glance is in
>[2].
>

Hi, Doug,

I am gonna do this in Mistral project, but I wonder how
releasenotes/source/conf.py is generated? since I found there are some
contents specific to Glance.


-- 
Regards!
-------
Lingxian Kong

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

Re: [openstack-dev] [mistral] Planning and prioritizing session for Mitaka

[Lingxian Kong]

Hi, Renat, thanks for bringing this, the time works for me as well.

On Thu, Nov 5, 2015 at 3:23 PM, Renat Akhmerov <rakhme...@mirantis.com> wrote:
> Team,
>
> We’ve done a great job at the summit discussing our most hot topics within 
> the project and a lot of important decisions were made. I would like to have 
> though one more session in IRC to wrap up this by going over all the BPs/bugs 
> we created in order to scope and prioritize them.
>
> I’m proposing next Monday 9 Nov at 7.00 UTC. If you have other time options 
> let’s communicate.
>
> Thanks
>
> Renat Akhmerov
> @ Mirantis Inc.
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Regards!
---
Lingxian Kong

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

[openstack-dev] [mistral] sort dir of executions, asc or desc?

[Lingxian Kong]

Hi, guys,

I found this bug[1] this morning which was fixed just now, and I have
to say, it is my intention that to make the query executions result in
descending order when I implemented the query pagination blueprint,
which is different with workflows list result behavior. Because in
user's perspective, I think it's more convinient to show the lasted
execution first, right? maybe the most commonly used scenario of
'execution-list' is, user creates some executions first, then he/she
just wants to see what's the status of them, it‘s inconvenience for
the users to scroll down the page to find their executions in
ascending order, executions are more time sensitive than workflows.

[1]: https://bugs.launchpad.net/mistral/+bug/1510417

-- 
Regards!
---
Lingxian Kong

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

Re: [openstack-dev] [release] establishing release liaisons for mitaka

[Lingxian Kong]

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 <d...@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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Regards!
---
Lingxian Kong

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

Re: [openstack-dev] [mistral] How to call 3rd-party tools(such as Ansible) in Mistral

[Lingxian Kong]

Hi, Minghao,

The answer is yes, if you want to use Ansible playbook in you
customized 'ansible actions', you need put the playbooks under a place
that your code has access to.

BTW, you can send personal email to me in Chinese, in case you want to
solve your problems quickly :-)

On Tue, Oct 20, 2015 at 4:58 PM, WANG, Ming Hao (Tony T)
<tony.a.w...@alcatel-lucent.com> wrote:
> Renat,
>
>
>
> 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?
>
>
>
> Thanks,
>
> Tony
>
>
>
> From: Renat Akhmerov [mailto:rakhme...@mirantis.com]
> Sent: Monday, October 19, 2015 2:58 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 19 Oct 2015, at 07:53, WANG, Ming Hao (Tony T)
> <tony.a.w...@alcatel-lucent.com> wrote:
>
>
>
> The “custom action” needs to re-install Mistral.
>
> If the Mistral service is part of 3rd party OpenStack, it may be
> unacceptable to let every user create his own customer action. What do you
> think?
>
>
>
> Yes, correct. It requires reinstall. If your goal is to give users
> possibility to create custom actions "on the fly” then it’s now impossible
> in Mistral for fundamental reasons. We can’t let users upload arbitrary
> Python code via API for security reasons. However, we have a couple of ideas
> that we’re going to explore in order to partially close this gap:
>
> Keep action code on a client-side, sort of what StackStorm does. But IMO we
> could think about automating it in a more elegant and transparent way. For
> example, we could use decorators in python code that would associate a
> function or a class with a certain workflow task. Then a workflow could call
> this code back while its running using some mechanism (i.e. some special
> action). In this case, however, we’d have to have a process handling
> callback requests from Mistral on a client side. The alternative: using HTTP
> Long Poll mechanism so that a client could claim available tasks itself.
> We have BP [1] that describes the idea of using so-called action providers.
> It assumes that we can register trustworthy action providers that could
> dynamically provide new actions to Mistral. I personally like this idea and
> to some extent it would solve this issue but it requires some additional
> setup which works for cases like StackStorm but doesn’t work if we want to
> use Mistral as is, as a hosted workflow service.
>
>
>
> Anyway, whatever solution we accept it will be a trade-off and depend on a
> particular use case.
>
>
>
> Ad-hoc actions may also work for you if, for example, we create enough base
> actions that they could be built upon. Say if most of your actions are HTTP
> based then you can just create your own library (e.g. a workbook) of ad-hoc
> actions that will be wrappers around std.http.
>
>
>
> Also look at what StackStorm does, it may also be helpful.
>
>
>
> Thanks
>
>
>
> [1] https://blueprints.launchpad.net/mistral/+spec/action-providers
>
>
> ______
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards!
---
Lingxian Kong

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

Re: [openstack-dev] [mistral] How to call 3rd-party tools(such as Ansible) in Mistral

[Lingxian Kong]

Or, feel free to join our IRC channel for quick response, #openstack-mistral

On Tue, Oct 20, 2015 at 4:58 PM, WANG, Ming Hao (Tony T)
<tony.a.w...@alcatel-lucent.com> wrote:
> Renat,
>
>
>
> 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?
>
>
>
> Thanks,
>
> Tony
>
>
>
> From: Renat Akhmerov [mailto:rakhme...@mirantis.com]
> Sent: Monday, October 19, 2015 2:58 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 19 Oct 2015, at 07:53, WANG, Ming Hao (Tony T)
> <tony.a.w...@alcatel-lucent.com> wrote:
>
>
>
> The “custom action” needs to re-install Mistral.
>
> If the Mistral service is part of 3rd party OpenStack, it may be
> unacceptable to let every user create his own customer action. What do you
> think?
>
>
>
> Yes, correct. It requires reinstall. If your goal is to give users
> possibility to create custom actions "on the fly” then it’s now impossible
> in Mistral for fundamental reasons. We can’t let users upload arbitrary
> Python code via API for security reasons. However, we have a couple of ideas
> that we’re going to explore in order to partially close this gap:
>
> Keep action code on a client-side, sort of what StackStorm does. But IMO we
> could think about automating it in a more elegant and transparent way. For
> example, we could use decorators in python code that would associate a
> function or a class with a certain workflow task. Then a workflow could call
> this code back while its running using some mechanism (i.e. some special
> action). In this case, however, we’d have to have a process handling
> callback requests from Mistral on a client side. The alternative: using HTTP
> Long Poll mechanism so that a client could claim available tasks itself.
> We have BP [1] that describes the idea of using so-called action providers.
> It assumes that we can register trustworthy action providers that could
> dynamically provide new actions to Mistral. I personally like this idea and
> to some extent it would solve this issue but it requires some additional
> setup which works for cases like StackStorm but doesn’t work if we want to
> use Mistral as is, as a hosted workflow service.
>
>
>
> Anyway, whatever solution we accept it will be a trade-off and depend on a
> particular use case.
>
>
>
> Ad-hoc actions may also work for you if, for example, we create enough base
> actions that they could be built upon. Say if most of your actions are HTTP
> based then you can just create your own library (e.g. a workbook) of ad-hoc
> actions that will be wrappers around std.http.
>
>
>
> Also look at what StackStorm does, it may also be helpful.
>
>
>
> Thanks
>
>
>
> [1] https://blueprints.launchpad.net/mistral/+spec/action-providers
>
>
> ______
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards!
---
Lingxian Kong

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

Re: [openstack-dev] [nova-compute][nova][libvirt] Extending Nova-Compute for image prefetching

[Lingxian Kong]

Hi, Alberto,

I'm really interested in your proposal, have you already submitted
your spec? or is there any topic for you to have a discussion with
Nova team in design summit?

I wonder what if the nova compute host use shared storage backend,
like NFS or Ceph?

I have another suggestion, we can consider adding this capability in
nova manage CLI, since it's just may be used by operator or
administrator(at least for create/update/delete command), right?

On Thu, Oct 8, 2015 at 7:50 PM, Alberto Geniola
<albertogeni...@gmail.com> wrote:
> Hi all,
>
> I'm considering to extend the Nova-Compute API in order to provide
> image-prefetching capabilities to OS.
>
> In order to allow image prefetching, I ended up with the need to add three
> different APIs on the nova-compute nodes:
>
>   1. Trigger an image prefetching
>
>   2. List prefetched images
>
>   3. Delete a prefetched image
>
>
>
> About the point 1 I saw I can re-use the libvirt driver function
> _create_image() to trigger the image prefetching. However, this approach
> will not store any information about the stored image locally. This leads to
> an issue: how do I retrieve a list of already fetched images? A quick and
> simple possibility would be having a local file, storing information about
> the fetched images. Would it be acceptable? Is there any best practice in OS
> community?
>
>
>
> Any ideas?
>
>
> Ty,
>
> Al.
>
>
> --
> Dott. Alberto Geniola
>
>   albertogeni...@gmail.com
>   +39-346-6271105
>   https://www.linkedin.com/in/albertogeniola
>
> Web: http://www.hw4u.it
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards!
---
Lingxian Kong

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

Re: [openstack-dev] [mistral] Team meeting minutes - 10/12/2015

[Lingxian Kong]

Hi, Mistral guys,

In last meeting, we have discussed deeply about Tempest usage in Mistral
project and the functional testing mechanism, I have the understanding in
terms of functional testing as below,

* run_functional_tests.sh is just used locally, will not run tests depend
on OpenStack.
* in our gate tests, all functional tests will run, since OpenStack will be
deployed before Mistral installed.

Am I right?

What's more, maybe I'm totally wrong about the Tempest usage in Mistral
functional testing and use it for DefCore purpose, I'm afraid Nikolay is
right, we can get rid of it totally, then we don't rely on it for our
testing. Or, we can use test plugin mechanism Tempest already provides(see
http://docs.openstack.org/developer/tempest/plugin.html), but I think we
are not interested in it in short term.

On Tue, Oct 13, 2015 at 1:06 AM, Renat Akhmerov <rakhme...@mirantis.com>
wrote:

> Hi,
>
> Thanks for joining team meeting today.
>
> Meeting minutes:
> http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-10-12-16.00.html
> Meeting log:
> http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-10-12-16.00.log.html
>
> See you next Monday at the same time.
>
> Renat Akhmerov
> @ Mirantis Inc.
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [nova] About availability zones

[Lingxian Kong]

Hi, Sylvain Nova guys,

Our team has also argued about this deeply, and no consensus was reached.

if instance.az is designed just for a reflect of the instance at boot
time, then it doesn't make any sense after the vm is live-migrated
with specified destination for several times, right?
Then, how could user get the exact az information for that vm? The
workaround I can think of is, user can query the host that vm is
running on, then query az that the host belongs to, is this the
recommended way?

On Wed, Sep 23, 2015 at 4:49 PM, Zhenyu Zheng <zhengzhenyul...@gmail.com> wrote:
> Hi,
>
> Thanks for the reply, one possible usecase is that user wants to
> live-migrate to az2 so he specified host2. As we didn't update the
> instance.az, if the user live-migrate again without specifiying destination
> host, the instance will migrate to az1 again, this might be different as the
> user expect. Any thought about this?
>
> BR,
>
> Zheng
>
> On Wed, Sep 23, 2015 at 4:30 PM, Sylvain Bauza <sba...@redhat.com> wrote:
>>
>>
>>
>> Le 23/09/2015 05:24, Zhenyu Zheng a écrit :
>>
>> Hi, all
>>
>> I have a question about availability zones when performing live-migration.
>>
>> Currently, when performing live-migration the AZ of the instance didn't
>> update. In usecase like this:
>> Instance_1 is in host1 which is in az1, we live-migrate it to host2
>> (provide host2 in API request) which is in az2. The operation will secusess
>> but the availability zone data stored in instance1 is still az1, this may
>> cause inconsistency with the az data stored in instance db and the actual
>> az. I think update the az information in instance using the host az can
>> solve this.
>>
>>
>> Well, no. Instance.AZ is only the reflect of what the user asked, not what
>> the current AZ is from the host the instance belongs to. In other words,
>> instance.az is set once forever by taking the --az hint from the API request
>> and persisting it in DB.
>>
>> That means that if you want to create a new VM without explicitly
>> specifying one AZ in the CLI, it will take the default value of
>> CONF.default_schedule_az which is None (unless you modify that flag).
>>
>> Consequently, when it will go to the scheduler, the AZFilter will not
>> check the related AZs from any host because you didn't asked for an AZ. That
>> means that the instance is considered "AZ-free".
>>
>> Now, when live-migrating, *if you specify a destination*, you totally
>> bypass the scheduler and thus the AZFilter. By doing that, you can put your
>> instance to another host without really checking the AZ.
>>
>> That said, if you *don't specify a destination*, then the scheduler will
>> be called and will enforce the instance.az field with regards to the host
>> AZ. That should still work (again, depending on whether you explicitly set
>> an AZ at the boot time)
>>
>> To be clear, there is no reason of updating that instance AZ field. We can
>> tho consider it's a new "request"' field and could be potentially moved to
>> the RequestSpec object, but for the moment, this is a bit too early since we
>> don't really use that new RequestSpec object yet.
>>
>>
>>
>> Also, I have heard from my collegue that in the future we are planning to
>> use host az information for instances. I couldn't find informations about
>> this, could anyone provide me some information about it if thats true?
>>
>>
>> See my point above, I'd rather prefer to fix how live-migrations check the
>> scheduler (and not bypass it when specifying a destination) and possibly
>> move the instance AZ field to the RequestSpec object once that object is
>> persisted, but I don't think we should check the host instead of the
>> instance in the AZFilter.
>>
>>
>> I assume all of that can be very confusing and mostly tribal knowledge,
>> that's why we need to document that properly and one first shot is
>> https://review.openstack.org/#/c/223802/
>>
>> -Sylvain
>>
>> Thanks,
>>
>> Best Regards,
>>
>> Zheng
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> __
>> Open

Re: [openstack-dev] [mistral] Cancelling team meeting today (09/28/2015)

[Lingxian Kong]

Hi, guys,

We will have a 7 days holiday in China, which is National Day, from
Oct. 1 to Oct. 7. So, I'll miss the next team meeting :(

On Mon, Sep 28, 2015 at 4:46 PM, Nikolay Makhotkin
<nmakhot...@mirantis.com> wrote:
> Mistral Team,
>
> We’re cancelling today’s team meeting because a number of key members won’t
> be able to attend.
>
> The next one is scheduled for 5 Oct.
>
>
> Best Regards,
> Nikolay Makhotkin
> @Mirantis Inc.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards!
---
Lingxian Kong

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

Re: [openstack-dev] [mistral][requirements] lockfile not in global requirements

[Lingxian Kong]

Hi, Andreas,

Sorry for the late response from Mistral. Anyway, I'm coming :-)

I'll take a look and solve it if needed, thanks for letting us know that.

On Fri, Sep 18, 2015 at 2:22 AM, Andreas Jaeger <a...@suse.com> wrote:

> The syncing of requirements fails from the requirements repository to
> mistral-extra with
> 'lockfile' is not in global-requirements.txt
>
> Mistral team, could you either propose to add lockfile to the global
> requirements file - or remove it from your project, please?
>
> for details see:
>
> https://jenkins.openstack.org/job/propose-requirements-updates/363/consoleFull
>
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

[openstack-dev] [Mistral] Mistral PTL Candidacy

[Lingxian Kong]

Greetings,

After contributing consistently to Mistral since the Kilo dev cycle, I'd
like to run for the Mistral PTL position for the Mikata release cycle.
In case you don't immediately recognize me, I'm 'xylan_kong' on IRC,
where you can always find me.

Although I know that I have served as Mistral core reviewer for only
less than 1 year, I make myself almost full-time dedicated to Mistral
upstream work, to make it more feature-riched, more stable, more
scalable, and align with the whole community rules, etc. I've also
helped many new developers contribute to Mistral project, and have tried
to always be available on IRC and mailing list, in the position to help.

Of course, I'd like to thanks to all the fantastic folks of Mistral core
team, although it's a really small team, but I've been honored to serve
under Renat, Nokolay, Winson and many others for this year, thanks all
to your mentoring, and now I feel I could try to serve as PTL, I am
fortunate enough to work for an employer that would allow me to focus
100% of my time on the role of PTL.

Some of my thoughts about Mistral for the Mikata cycle are as follows:

* Improving the growth and vitality of Mistral project
People of Mistral team may know that there are not a lot of contributors
interested in Mistral, it’s important that as PTL, spent time on
non-technical duties besides technical effort, such as actively seek out
the input and feedback from users, operators and deployers, as well as
mentoring others to become future core contributor and even project team
leads, and acting as a point of contact for other OpenStack projects.

* Continuing to improve Mistral UI and Mistral documentation
Thanks to all the talent guys for their tremendous efforts for UI and
doc (you know who what I mean :-)), we have already make a big progress
for Mistral UI work and doc reference. However, We still need to put
more efforts on that, since UI is so important to Mistral usage, no
matter for end users usage or for PoC scenarios.

* Participating in cross-project initiatives and discussion in OpenStack
Actions involved in like: collaborating with the API working group,
cross-project specs, QA team, release team, etc. We should be reviewing
specs from these teams and making sure we implement those initiatives in
a timely fashion. For example: designing our new API version according
to API guideline, keeping with pace with other projects before the
release schedule deadline, integrating with OpenStack client, showing we
are part of community as a whole like many other official projects, etc.

* Introducing spec repository for Mistral (or something else we think it
better for tracking design details)
As I mentioned before, Mistral is a small project compared to many other
projects, but that doesn't mean we could do anything 'freely'. A good
thing recently is, we started to use etherpad to bring new features for
discussion before people decide to implement. However, etherpad is so
fragile that we may lose the 'history' of feature evolvement process,
I'd like to propose we use a specific git repository (*-specs) or
something like that to propose, discuss, iterate and track approvals on
specifications using Gerrit instead of Launchpad, like other projects,
which is very useful for new comers to learn how Mistral evolves, where
we are, and where we're going.

* Last but not least, bringing more and more useful features to Mistral,
increasing Mistral stability at the same time.

There are other things I'd like to accomplish as well, but those are the
main pieces in my mind when I decide to run for PTL. I know the chance
is very small for me to be elected, but I still wanna have a try,
regardless of the outcome.

I'm looking forward to serving the Mistral community during Mitaka, as I
always did before.

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

Re: [openstack-dev] [mistral] Displaying wf hierarchy in CLI

[Lingxian Kong]

Hi, Renat,

I want to make it clear. Then, what you want to see is dependencies between
workflow executions? or task executions in one workflow? We know that we
could use a separate task or a workflow as a 'task'.

On Wed, Sep 2, 2015 at 3:33 PM, Renat Akhmerov <rakhme...@mirantis.com>
wrote:

>
> On 01 Sep 2015, at 22:21, Lingxian Kong <anlin.k...@gmail.com> wrote:
>
> To achieve that, we should record the execution/task-execution
> relationship during an execution is running, because we have no such info
> currently.
>
>
> Well, in DB model we, in fact, have a field pointing to parent task
> execution id (and hence we can figure out workflow execution id easily),
> it’s required because child workflow needs to communicate its result to its
> parent workflow somehow. But it’s not displayed anywhere. So we can use
> this field.
>
>
> Renat Akhmerov
> @ Mirantis Inc.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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