Re: [openstack-dev] [Congress] kilo bug on datasource listing

[Anusha Ramineni]

Yes, this is fixed in liberty as part of this bug ,
https://bugs.launchpad.net/congress/+bug/1492354.
I have cherry-picked the same onto kilo branch -
https://review.openstack.org/#/c/248514/

Best Regards,
Anusha

On 21 November 2015 at 06:07, Tim Hinrichs  wrote:

> Congress stable-maintenance team:
>
> We seem to have a bug in kilo that is making it tough for Bryan Sullivan
> to get things up and running.  The swift driver doesn't have a 'secret'
> field, which is causing a 500 error when listing datasources.  If I
> remember right, we fixed this bug later.
>
> https://bugs.launchpad.net/congress/+bug/1518496
>
> Could someone volunteer to fix it?  I think we should do a release once
> that's in.
>
> Tim
>
> __
> 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] [Ceilometer]:Subscribe and Publish Notification frame work in Ceilometer !

[Srikanth Vavilapalli]

Thanks very much Gord for the pointers.

I have looked at this file reload feature and it addresses some part of my 
problem description (avoiding the restart of the ceilometer services to reflect 
the pipeline changes). However, this still requires users to directly access 
the internal ceilometer file (pipeline.yaml) to make any updates to pipeline. 
There are no APIs introduced as part of this feature to allow user to 
configure/unconfigure these pipeline. In one of the deployment that we are 
currently looking for, we wanted to expose only ceilometer API service to the 
users and block access to any internal modules of ceilometer. In the same 
deployment, we are also thinking of allowing users to configure/unconfigure a 
pipeline for a set of meters for only a subset of resources instead of getting 
notified about events/meters of all the resources as shown below.

sources:
- name: user1_meter_source
  meters:
  - "cpu_util"
  query/filter:
  - {{field:"project_id",op:"eq",value:"11"}}
  sinks:
  - user1_meter_sink
sinks:
- name: user1_meter_sink
  transformers:
  publishers:
  - udp://:


We have found a related blueprint [1], which is exactly addressing this dynamic 
provisioning of pipelines via an API and making use of a new data store to 
store this configuration. But seems like that blueprint was abandoned due its 
limited usage. We agree that it may not be that frequent operation to change 
the pipeline configuration in all deployments, but in certain deployments, 
where applications desire to turn ON/OFF receiving these notifications based on 
some other trigger (like anomaly detection, where application might have sensed 
an anomaly based on some set of meters and wanted to turn ON few additional set 
of event/meters to confirm that and turn OFF once the anomaly is confirmed).

Thanks
Srikanth

[1] 
https://wiki.openstack.org/wiki/Ceilometer/blueprints/Configuration-via-data-store



From: gord chung [mailto:g...@live.ca]
Sent: Thursday, November 19, 2015 9:08 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Ceilometer]:Subscribe and Publish Notification 
frame work in Ceilometer !


On 19/11/15 10:26 PM, Srikanth Vavilapalli wrote:
Hi Gord

On your second point, Yes, Ceilometer does provide a framework to capture a 
notification and republish to multiple "publish targets" in addition to the 
collector service using udp/kafka/notification as the transport mechanisms... 
We believe this is how "Event Alarm Evaluator" module in Aodh project get 
notified directly from Notification Agents.

However seems like the configuration of these additional "publish targets" is 
supported only through updating the pipeline_cfg_file and restarting the 
corresponding ceilometer services. i.e. the users need to manually update the 
pipeline config files to insert their "publish targets" in the sink-publisher 
configuration for a set of event filters of their interest. This type of 
provisioning is very static.

As per our understanding, ceilometer currently does not provide means for users 
to dynamically register/unregister their "publish targets" with ceilometer 
framework for a subset events of their interest? i.e User invokes a ceilometer 
API with a set of event filters and associated publish targets, that can be 
stored in a data store, which will eventually be used by the ceilometer 
Publisher to dispatch the notification to those configured destinations in 
addition to the statically configured "publish targets". Plz let us know if our 
understanding is wrong or if there are any other means to achieve the above 
functionality. We believe this as a very key functionality needed to build 
latency sensitive (sub-second) analytics application on-top of ceilometer 
framework. We are seeking the feedback from community on having this kind of 
functionality inside ceilometer before proceeding with blueprint submission.
actually, in Liberty you can configure a reload[1][2] to refresh pipeline when 
a change happens. based on survey results, most operators don't need this 
functionality so it's off by default but it seems you do. :)

[1] 
https://specs.openstack.org/openstack/ceilometer-specs/specs/liberty/reload-file-based-pipeline-configuration.html
[2] 
https://github.com/openstack/ceilometer/blob/master/ceilometer/pipeline.py#L50-L58

cheers,



--

gord
__
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] [devstack] How to source openrc?

[Ian Wienand]

On 11/23/2015 03:17 PM, Wilence Yao wrote:
> source openrc admin admin
> openrc:90: unknown condition: -v

I'm pretty sure you're using zsh -- we only support bash (stack.sh
checks for bash, maybe we should add that to openrc)

Anyway, you can probably follow [1] to source it; other things might
break though

-i

[1] 
http://docs.openstack.org/developer/devstack/faq.html#can-i-at-least-source-openrc-with-zsh

__
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] [tripleo] When to use parameters vs parameter_defaults

[Juan Antonio Osorio]

On Sat, Nov 21, 2015 at 2:05 AM, Ben Nemec  wrote:

> Thinking about this some more makes me wonder if we need a sample config
> generator like oslo.config.  It would work off something similar to the
> capabilities map, where you would say
>
> SSL:
>   templates:
> -puppet/extraconfig/tls/tls-cert-inject.yaml
>   output:
> -environments/enable-ssl.yaml
>
> And the tool would look at that, read all the params from
> tls-cert-inject.yaml and generate the sample env file.  We'd have to be
> able to do a few new things with the params in order for this to work:
>
> -Need to specify whether a param is intended to be set as a top-level
> param, parameter_defaults (which we informally do today with the Can be
> overridden by parameter_defaults comment), or internal, to define params
> that shouldn't be exposed in the sample config and are only intended as
> an interface between templates.  There wouldn't be any enforcement of
> the internal type, but Python relies on convention for its private
> members so there's precedent. :-)
>
Perhaps a convention could be done in a similar fashion to how things are
done in
python. Where parameters passed from top-level could be defined as they are
defined
now (with camel-case type of definition) and non-top-parameters could be
defined with
lowercase and underscores (or with an underscore prefix). That could make
things
clearer and allow us to have a more programmatic approach in the future.

> -There would have to be some way to pick out only certain params from a
> template, since I think there are almost certainly features that are
> configured using a subset of say puppet/controller.yaml which obviously
> can't just take the params from an entire file.  Although maybe this is
> an indication that we could/should refactor the templates to move some
> of these optional params into their own separate files (at this point I
> think I should take a moment to mention that this is somewhat of a brain
> dump, so I haven't thought through all of the implications yet and I'm
> not sure it all makes sense).
>
> The nice thing about generating these programmatically is we would
> formalize the interface of the templates somewhat, and it would be
> easier to keep sample envs in sync with the actual implementation.
> You'd never have to worry about someone adding a param to a file but
> forgetting to update the env (or at least it would be easy to catch and
> fix when they did, just run "tox -e genconfig").
>
I think having such a tool is an excellent idea.

>
> I'm not saying this is a simple or short-term solution, but I'm curious
> what people think about setting this as a longer-term goal, because as I
> think our discussion in Tokyo exposed, we're probably going to have a
> bit of an explosion of sample envs soon and we're going to need some way
> to keep them sane.
>
> Some more comments inline.
>
> On 11/19/2015 10:16 AM, Steven Hardy wrote:
> > On Mon, Nov 16, 2015 at 08:15:48PM +0100, Giulio Fidente wrote:
> >> On 11/16/2015 04:25 PM, Steven Hardy wrote:
> >>> Hi all,
> >>>
> >>> I wanted to start some discussion re $subject, because it's been
> apparrent
> >>> that we have a lack of clarity on this issue (and have done ever since
> we
> >>> started using parameter_defaults).
> >>
> >> [...]
> >>
> >>> How do people feel about this example, and others like it, where we're
> >>> enabling common, but not mandatory functionality?
> >>
> >> At first I was thinking about something as simple as: "don't use
> top-level
> >> params for resources which the registry doesn't enable by default".
> >>
> >> It seems to be somewhat what we tried to do with the existing pluggable
> >> resources.
> >>
> >> Also, not to hijack the thread but I wanted to add another question
> related
> >> to a similar issue:
> >>
> >>   Is there a reason to prefer use of parameters: instead of
> >> parameter_defaults: in the environment files?
> >>
> >> It looks to me that by defaulting to parameter_defaults: users won't
> need to
> >> update their environment files in case the parameter is moved from
> top-level
> >> into a specific nested stack so I'm inclined to prefer this. Are there
> >> reasons not to?
> >
> > The main reason is scope - if you use "parameters", you know the data
> flow
> > happens via the parent template (e.g overcloud-without-mergepy) and you
> > never have to worry about naming collisions outside of that template.
> >
> > But if you use parameter_defaults, all parameters values defined that way
> > are effectively global, and you then have to be much more careful that
> you
> > never shadow a parameter name and get an unexpected value passed in to
> it.
> >
> > Here's another example of why we need to decide this btw:
> >
> > https://review.openstack.org/#/c/229471/
> >
> > Here, we have some workers parameters, going only into controller.yaml -
> > this is fine, but the new options are completely invisible to users who
> > look at the 

Re: [openstack-dev] [neutron][taas] proposal: dedicated tunnel for carrying mirrored traffic

[Fawad Khaliq]

Hi Kazuhiro,

On Fri, Nov 20, 2015 at 3:29 PM, SUZUKI, Kazuhiro 
wrote:

> Hi,
>
> Thank you for your interest and suggestion.
>
> A blueprint [1] has already proposed to add port mirroring
> capabilities to Neutron.
>
> [1] https://blueprints.launchpad.net/neutron/+spec/port-mirroring


Can we please restore this [1] and have the reviews complete. I believe
there is a lot of interest in this and we will need to consider multiple
use case scenarios. This [1] will be the best place to capture and discuss.

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

Thanks,
Fawad Khaliq


>
>
> Because our proposal is for the current design of TaaS
> (tap-as-a-service), I guess a RFE is not required at this time.
>
> Thank you.
>
> --
> Kazuhiro Suzuki
>
>
> From: Li Ma 
> Subject: Re: [openstack-dev] [neutron][taas] proposal: dedicated tunnel
> for carrying mirrored traffic
> Date: Thu, 19 Nov 2015 11:51:15 +0800
>
> > It is suggested that you can issue a RFE request for it. [1] We can
> > discuss with it and track the progress in the launchpad.
> >
> > By the way, I'm very interested in it. I discussed a another problem
> > with Huawei neutron engineers about abstract VTEP to neutron port. It
> > allows managing VTEP and can leverage the flexibility in many aspects
> > as more and more neutron features need VTEP management, just like your
> > proposal.
> >
> > [1] http://docs.openstack.org/developer/neutron/policies/blueprints.html
> >
> > On Thu, Nov 19, 2015 at 11:36 AM, Soichi Shigeta
> >  wrote:
> >>
> >>  Hi,
> >>
> >> As we decided in the last weekly meeting,
> >>   I'd like to use this mailing list to discuss
> >>   a proposal about creating dedicated tunnel for
> >>   carrying mirrored traffic between hosts.
> >>
> >>   link:
> >>
> https://wiki.openstack.org/w/images/7/78/TrafficIsolation_20151116-01.pdf
> >>
> >>   Best Regards,
> >>   Soichi Shigeta
> >>
> >>
> >>
> >>
> __
> >> 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
> >
> >
> >
> > --
> >
> > Li Ma (Nick)
> > Email: skywalker.n...@gmail.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
>
__
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] [Fuel] Approved but not implemented specs

[Dmitry Borodaenko]

On Fri, Nov 20, 2015 at 07:04:47PM -0800, Oleg Gelbukh wrote:
> It's a good point.
> 
> I think it could even be done automatically: once spec freeze is in place,
> run an infra script and update all CRs still in review with specs targeted
> to current (and previous) releases by moving them to next release's
> directory.

Igor was asking about the specs that got _merged_, not the ones still on
review. For specs on review, I think automation would be an overkill: in
most cases, the spec author will still have to update the spec contents
for the next release, moving the file to a different directory is too
easy to justify automation.

> On Fri, Nov 20, 2015 at 3:35 PM, Igor Kalnitsky 
> wrote:
> > Today I noticed that some of Fuel specs have been merged for 7.0 while
> > the features themselves weren't landed. It's kind confusing since it
> > seems like the feature was implemented in 7.0 while it's not.
> >
> > What do you think guys about moving such specs into 8.0 folder? I
> > believe it's a way to better understand what we're doing now, and what
> > was done previously.

+1 for moving a spec to the 8.0 folder if the feature was implemented in
8.0. If it's not likely that it will be implemented before FF, better to
move it all the way to the 9.0 folder.

-- 
Dmitry Borodaenko

__
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] [nova-scheduler] Scheduler sub-group meeting - Agenda 11/

[Dugger, Donald D]

Meeting on #openstack-meeting-alt at 1400 UTC (7:00AM MDT)

1) Spec & BPs - 
https://etherpad.openstack.org/p/mitaka-nova-spec-review-tracking
2) Bugs - https://bugs.launchpad.net/nova/+bugs?field.tag=scheduler
3) Opens

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786



__
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] [cinder][glance]Upload encrypted volumes to images

[Philipp Marek]

> About uploading encrypted volumes to image, there are three options:
> 1. Glance only keeps non-encrypted images. So when uploading encrypted 
>volumes to image, cinder de-crypts the data and upload.
> 2. Glance maintain encrypted images. Cinder just upload the encrypted 
>data to image. 
> 3. Just prevent the function to upload encrypted volumes to images.
>
> Option 1 No changes needed in Glance. But it may be not safe. As we decrypt 
> the data, and upload it to images. 
> Option 2 This imports encryption to Glance which needs to manage the 
> encryption metadata.
> 
> Please add more if you have other suggestions. How do you think which one is 
> preferred.
Well, IMO only option 1 is useful.

Option 2 means that the original volume, the image, and all derived volumes 
will share the same key, right?
That's not good. (Originally: "unacceptable")


__
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][fwaas]some architectural advice on fwaas driver writing

[Germy Lure]

Hi,
Under current FWaaS architecture or framework, only integrating hardware
firewall is not easy. That requires neutron support service level multiple
vendors. In another word, vendors must fit each other for their services
while currently vendors just provides all services through controller.

I think the root cause is Neutron just doesn't known how the network
devices connect each other.  Neutron provides FW, LB, VPN and other
advanced network functionalists as services. But as the implementation
layer, Neutron needs TOPO info to make right decision, routing traffic to
the right device. For example, from namespace router to hardware firewall,
Neutron should add some internal routes even extra L3 interfaces according
to the connection relationship between them. If the firewall service is
integrated with router, like Vyatta, it's simple. The only thing you need
to do is just enable the firewall itself.

All in all, it requires linkage between services, especially between
advanced services and L3 router.

Germy
.

On Fri, Nov 20, 2015 at 9:19 PM, Somanchi Trinath <
trinath.soman...@freescale.com> wrote:

> Hi-
>
>
>
> As I understand you are not sure on “How to locate the Hardware Appliance”
> which you have as your FW?
>
>
>
> Am I right?  If so you can look into,
> https://github.com/jumpojoy/generic_switch kind of approach.
>
>
>
> -
>
> Trinath
>
>
>
>
>
>
>
> *From:* Oguz Yarimtepe [mailto:oguzyarimt...@gmail.com]
> *Sent:* Friday, November 20, 2015 5:52 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [neutron][fwaas]some architectural advice
> on fwaas driver writing
>
>
>
> I created a sample driver by looking at vArmour driver that is at the
> Github FWaaS repo. I am planning to call the FW's REST API from the
> suitable functions.
>
> The problem is, i am still not sure how to locate the hardware appliance.
> One of the FWaaS guy says that Service Chaining can help, any body has an
> idea or how to insert the fw to OpenStack?
>
> On 11/02/2015 02:36 PM, Somanchi Trinath wrote:
>
> Hi-
>
>
>
> I’m confused. Do you really have an PoC implementation of what is to be
> achieved?
>
>
>
> As I look into these type of Implementations, I would prefer to have proxy
> driver/plugin to get the configuration from Openstack to external
> controller/device and do the rest of the magic.
>
>
>
> -
>
> Trinath
>
>
>
> __
> 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] [Fuel] Getting rid of Docker containers on the Fuel master node

[Anastasia Urlapova]

@Vova,
thanks for bringing this up.
The new approach without docker containers on master node really has many
advantages.

@Igor,
regarding your question, I would say that we have many dependencies from
containers in CI/CD systems and test's codebase. The test alignment to the
new implementation won't be easy. In such things we should move forward
step by step.
As you know the first step is a spec file, can you give us a link to it?


Nastya.

On Sat, Nov 21, 2015 at 6:10 AM, Oleg Gelbukh  wrote:

> With CentOS7 we will have python2.7 at Fuel Admin node as a default
> version, I believe.
>
> --
> Best regards,
> Oleg Gelbukh,
> Principal Engineer
> Mirantis
>
> On Fri, Nov 20, 2015 at 6:27 AM, Timur Nurlygayanov <
> tnurlygaya...@mirantis.com> wrote:
>
>> Hi Andrey,
>>
>> As far as I remember from the last usage of fuel master node, there was
>>> Centos + py26 installation. Python 2.6 is old enough and sometimes it is
>>> hard to launch some application on fuel node without docker (image with
>>> py27/py3). Are you planning to provide py27 at least or my note is outdated
>>> and I can already use py27 from the box?
>>
>> We can install docker on master node anyway to run Rally / Tempest or
>> other test suites and scripts from master node with Python 2.7 or something
>> also.
>>
>> On Fri, Nov 20, 2015 at 5:20 PM, Andrey Kurilin 
>> wrote:
>>
>>> Hi!
>>> I'm not fuel developer, so opinion below is based on user-view.
>>> As far as I remember from the last usage of fuel master node, there was
>>> Centos + py26 installation. Python 2.6 is old enough and sometimes it is
>>> hard to launch some application on fuel node without docker (image with
>>> py27/py3). Are you planning to provide py27 at least or my note is outdated
>>> and I can already use py27 from the box?
>>>
>>> On Thu, Nov 19, 2015 at 4:59 PM, Vladimir Kozhukalov <
>>> vkozhuka...@mirantis.com> wrote:
>>>
 Dear colleagues,

 As might remember, we introduced Docker containers on the master node a
 while ago when we implemented first version of Fuel upgrade feature. The
 motivation behind was to make it possible to rollback upgrade process if
 something goes wrong.

 Now we are at the point where we can not use our tarball based upgrade
 approach any more and those patches that deprecate upgrade tarball has been
 already merged. Although it is a matter of a separate discussion, it seems
 that upgrade process rather should be based on kind of backup and restore
 procedure. We can backup Fuel data on an external media, then we can
 install new version of Fuel from scratch and then it is assumed backed up
 Fuel data can be applied over this new Fuel instance. The procedure itself
 is under active development, but it is clear that rollback in this case
 would be nothing more than just restoring from the previously backed up
 data.

 As for Docker containers, still there are potential advantages of using
 them on the Fuel master node, but our current implementation of the feature
 seems not mature enough to make us benefit from the containerization.

 At the same time there are some disadvantages like

- it is tricky to get logs and other information (for example, rpm
-qa) for a service like shotgun which is run inside one of containers.
- it is specific UX when you first need to run dockerctl shell
{container_name} and then you are able to debug something.
- when building IBP image we mount directory from the host file
system into mcollective container to make image build faster.
- there are config files and some other files which should be
shared among containers which introduces unnecessary complexity to the
whole system.
- our current delivery approach assumes we wrap into rpm/deb
packages every single piece of the Fuel system. Docker images are not an
exception. And as far as they depend on other rpm packages we forced to
build docker-images rpm package using kind of specific build flow. 
 Besides
this package is quite big (300M).
- I'd like it to be possible to install Fuel not from ISO but from
RPM repo on any rpm based distribution. But it is double work to support
both Docker based and package based approach.

 Probably some of you can give other examples. Anyway, the idea is to
 get rid of Docker containers on the master node and switch to plane package
 based approach that we used before.

 As far as there is nothing new here, we just need to use our old
 site.pp (with minimal modifications), it looks like it is possible to
 implement this during 8.0 release cycle. If there are no principal
 objections, please give me a chance to do this ASAP (during 8.0), I know it
 is a huge risk for the release, but still I think I can do 

Re: [openstack-dev] [cinder][glance]Upload encrypted volumes to images

[Duncan Thomas]

(1) is what we were working towards. To my mind, it is the right option.

(2) Means that you have an encryption key shared between volumes, same as
backups currently. It also means you can't share images, which is very
limiting.

(3) Makes BFV basically useless with encrypted volumes. Given there are
plenty of people who'd like to use BFV and need encrypted volumes, we'd
basically be pushing those people off to a backend that manages encryption
itself, which none of the free/libre backends do currently AFAIK.

On 23 November 2015 at 05:45, Li, Xiaoyan  wrote:

> Hi all,
> More help about volume encryption is needed.
>
> About uploading encrypted volumes to image, there are three options:
> 1. Glance only keeps non-encrypted images. So when uploading encrypted
> volumes to image, cinder de-crypts the data and upload.
> 2. Glance maintain encrypted images. Cinder just upload the encrypted data
> to image.
> 3. Just prevent the function to upload encrypted volumes to images.
>
> Option 1 No changes needed in Glance. But it may be not safe. As we
> decrypt the data, and upload it to images.
> Option 2 This imports encryption to Glance which needs to manage the
> encryption metadata.
>
> Please add more if you have other suggestions. How do you think which one
> is preferred.
> Appreciate for your help.
>
> Best wishes
> Lisa
>
>
>
> __
> 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
>



-- 
-- 
Duncan Thomas
__
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] [devstack] How to source openrc?

[Tony Breeds]

On Mon, Nov 23, 2015 at 12:17:13PM +0800, Wilence Yao wrote:
> Hi all,
> 
> In devstack stable/liberty, error is :
> 
> source openrc admin admin
> openrc:90: unknown condition: -v
> 
> the line 90 and code block in openrc is
> ```
> # Set OS_CACERT to a default CA certificate chain if it exists.
> if [[ ! -v OS_CACERT ]] ; then
> DEFAULT_OS_CACERT=$INT_CA_DIR/ca-chain.pem
> # If the file does not exist, this may confuse preflight sanity checks
> if [ -e $DEFAULT_OS_CACERT ] ; then
> export OS_CACERT=$DEFAULT_OS_CACERT
> fi
> fi
> ```
> So how to source devstack/openrc ? What command it is ?

You shell needs to be bash 4 (IIRC bash 3 won't do)
then:
 . openrc admin admin

Yours Tony.


pgpXs2_0bKhgk.pgp
Description: PGP signature
__
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] [oslo] Please stop removing usedevelop from tox.ini (at least for now)

[Robert Collins]

Workaround for what?

-Rob

On 23 November 2015 at 19:39, Angus Lees  wrote:
> The workaround I found is to set this in tox.ini:
>
> install_command =
>  sh -c 'pip install -U "pip>=6" && pip install -U "$@"' pip {opts}
> {packages}
>
> It's pretty ugly, but works fine and was unfortunately the only way I could
> find to update a dependency before parsing requirements.txt.
>
>  - Gus
>
> On Tue, 17 Nov 2015 at 06:25 Doug Hellmann  wrote:
>>
>> Excerpts from gord chung's message of 2015-11-16 12:04:27 -0500:
>> >
>> > On 16/11/2015 11:13 AM, Doug Hellmann wrote:
>> > >   does anyone want to sign up to remove that last
>> > > namespace package?
>> > already in action: https://review.openstack.org/#/c/243255/
>> >
>>
>> Thanks, Gordon!
>>
>> __
>> 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
>



-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
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][taas] proposal: dedicated tunnel for carrying mirrored traffic

[Fawad Khaliq]

On Thu, Nov 19, 2015 at 8:51 AM, Li Ma  wrote:

> It is suggested that you can issue a RFE request for it. [1] We can
> discuss with it and track the progress in the launchpad.
>
> By the way, I'm very interested in it. I discussed a another problem
> with Huawei neutron engineers about abstract VTEP to neutron port. It
> allows managing VTEP and can leverage the flexibility in many aspects
> as more and more neutron features need VTEP management, just like your
> proposal.
>
+1 to the use case. Have you looked at L2 Gateway APIs?
l2-gateway-connection creates a port on a network. Does that suffice the
requirements of the use case you are referring to or you need a port on the
'other' side of the VTEP, where physical resources are and use case
requires mirroring traffic to the external endpoint.


>
> [1] http://docs.openstack.org/developer/neutron/policies/blueprints.html
>
> On Thu, Nov 19, 2015 at 11:36 AM, Soichi Shigeta
>  wrote:
> >
> >  Hi,
> >
> > As we decided in the last weekly meeting,
> >   I'd like to use this mailing list to discuss
> >   a proposal about creating dedicated tunnel for
> >   carrying mirrored traffic between hosts.
> >
> >   link:
> >
> https://wiki.openstack.org/w/images/7/78/TrafficIsolation_20151116-01.pdf
> >
> >   Best Regards,
> >   Soichi Shigeta
> >
> >
> >
> >
> __
> > 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
>
>
>
> --
>
> Li Ma (Nick)
> Email: skywalker.n...@gmail.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] [all] [oslo] Please stop removing usedevelop from tox.ini (at least for now)

[Angus Lees]

The workaround I found is to set this in tox.ini:

install_command =
 sh -c 'pip install -U "pip>=6" && pip install -U "$@"' pip {opts}
{packages}

It's pretty ugly, but works fine and was unfortunately the only way I could
find to update a dependency before parsing requirements.txt.

 - Gus

On Tue, 17 Nov 2015 at 06:25 Doug Hellmann  wrote:

> Excerpts from gord chung's message of 2015-11-16 12:04:27 -0500:
> >
> > On 16/11/2015 11:13 AM, Doug Hellmann wrote:
> > >   does anyone want to sign up to remove that last
> > > namespace package?
> > already in action: https://review.openstack.org/#/c/243255/
> >
>
> Thanks, Gordon!
>
> __
> 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] Security Groups OVS conntrack support

[Fawad Khaliq]

Hi Gal,

On Sun, Nov 22, 2015 at 11:28 PM, Gal Sagie  wrote:

> Hi Fawad,
>
> From what i could understand from Miguel Angel Ajo, someone is working on
> this integration and it
> is suppose to be delivered as part of Mitaka.
> I don't remember the person name, Miguel will sure update shortly.
>

Great. Thanks!


>
> Gal.
>
> On Sun, Nov 22, 2015 at 7:05 PM, Fawad Khaliq  wrote:
>
>> Folks,
>>
>> Is there a plan to add conntrack support to the security groups for the
>> OVS driver in Mitaka cycle?
>>
>> My understanding is that it is being actively worked on for
>> networking-ovn but no concrete plan for support in the OVS Neutron driver
>> yet.
>>
>> Thanks,
>> Fawad Khaliq
>>
>>
>> __
>> 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 ,
>
> The G.
>
> __
> 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][ThirdPartyCI] Running third party CI on networking-foo projects

[Fawad Khaliq]

On Fri, Nov 20, 2015 at 8:26 AM, Takashi Yamamoto 
wrote:

> On Fri, Nov 20, 2015 at 2:27 AM, Fawad Khaliq  wrote:
> > Thanks a lot, Yamamoto.
> >
> > kakuma, I am assuming if you were able to set it up for a ofagent repo,
> then
> > it should have been the standard procedure documented here [1]. I reach
> out
> > to infra for any help.
> >
> > [1] http://docs.openstack.org/infra/system-config/third_party.html
> >
> > Fawad Khaliq
>
> here's an instruction in case you can read japanese. :-)
> https://github.com/osrg/ryu-neutron-zuul-ci/blob/master/doc/install.ja.txt

Thanks, Yamamoto. With a few days spent in Japan, I think I am ready to
give it a shot ;-)


>
>
> >
> >
> > On Wed, Nov 18, 2015 at 9:03 AM, Takashi Yamamoto  >
> > wrote:
> >>
> >> hi,
> >>
> >> On Wed, Nov 18, 2015 at 2:00 AM, Fawad Khaliq 
> wrote:
> >> > Folks,
> >> >
> >> > What would be the mechanism to enable a third party CI on a Neutron
> >> > sub-project? I am not sure if anyone has already tried it.
> >>
> >> networking-ofagent has its third party CI running.
> >> you can ask kakuma for details.
> >>
> >> >
> >> > I am interesting in adding PLUMgrid CI on networking-plumgrid [1]
> >> >
> >> > cc: Mike
> >> >
> >> > [1] https://github.com/openstack/networking-plumgrid
> >> >
> >> > Thanks,
> >> > Fawad Khaliq
> >> >
> >> >
> >> >
> >> >
> __
> >> > 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

Re: [openstack-dev] [Neutron][ThirdPartyCI] Running third party CI on networking-foo projects

[Fawad Khaliq]

Hi kakuma,

No worries and thanks a lot for the help. Seems like the process is similar
to the one we followed for the setting up the CI with Neutron. Wanted
confirmation and you helped.

Thanks,
Fawad Khaliq


On Sun, Nov 22, 2015 at 6:22 PM, fumihiko kakuma 
wrote:

> Hi Fawad,
>
> I am sorry for the late reply.
>
> On Fri, 20 Nov 2015 12:26:05 +0900
> Takashi Yamamoto  wrote:
>
> > On Fri, Nov 20, 2015 at 2:27 AM, Fawad Khaliq 
> wrote:
> > > Thanks a lot, Yamamoto.
> > >
> > > kakuma, I am assuming if you were able to set it up for a ofagent
> repo, then
> > > it should have been the standard procedure documented here [1]. I
> reach out
> > > to infra for any help.
> > >
> > > [1] http://docs.openstack.org/infra/system-config/third_party.html
> > >
>
> I also don't know the standard document other than it.
>
> > > Fawad Khaliq
> >
> > here's an instruction in case you can read japanese. :-)
> >
> https://github.com/osrg/ryu-neutron-zuul-ci/blob/master/doc/install.ja.txt
> >
>
> The updated document for the above can be found from the following URL.
> (That also is only japanese.)
> https://github.com/osrg/ofaci-inst/blob/master/docs/install.ja.txt
>
> But I don't try the procedure since installed in environment for juno.
> It may not work well, because infra repository had big change.
>
> I also refered to the following pages
> (but they don't seem to be updated).
>
>
> http://www.joinfu.com/2014/02/setting-up-an-external-openstack-testing-system/
>
> http://www.joinfu.com/2014/02/setting-up-an-openstack-external-testing-system-part-2/
>
> You may also obtain any information about CI attending at the thirdparty
> meeting.
>
> https://wiki.openstack.org/wiki/Meetings/ThirdParty
>
> On the other hand if you only want to run CI for the change to your
> project,
> you should add project-config/jenkins/jobs/networking-prumgrid.yaml.
> For eaxample, like https://review.openstack.org/#/c/198740/
>
>
> > >
> > >
> > > On Wed, Nov 18, 2015 at 9:03 AM, Takashi Yamamoto <
> yamam...@midokura.com>
> > > wrote:
> > >>
> > >> hi,
> > >>
> > >> On Wed, Nov 18, 2015 at 2:00 AM, Fawad Khaliq 
> wrote:
> > >> > Folks,
> > >> >
> > >> > What would be the mechanism to enable a third party CI on a Neutron
> > >> > sub-project? I am not sure if anyone has already tried it.
> > >>
> > >> networking-ofagent has its third party CI running.
> > >> you can ask kakuma for details.
> > >>
> > >> >
> > >> > I am interesting in adding PLUMgrid CI on networking-plumgrid [1]
> > >> >
> > >> > cc: Mike
> > >> >
> > >> > [1] https://github.com/openstack/networking-plumgrid
> > >> >
> > >> > Thanks,
> > >> > Fawad Khaliq
> > >> >
> > >> >
> > >> >
> > >> >
> __
> > >> > 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
>
> --
> fumihiko kakuma 
>
>
>
> __
> 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] Fwd: [Senlin]Support more complicated scaling scenario

[jun.xu...@139.com]

Thanks HU yanyan, I still has some question about your answers, and I respond 
inline.


2015-11-20 16:06 GMT+08:00 xu...@cmss.chinamobile.com 
:
Thanks yanyan!

Xu Jun is a contributor from CMCC. He asked a very interesting question about 
cluster scaling support in Senlin. To make the discussion more thorough, I just 
post the question and my answer here.

The question from Jun is as following:

For an action, senlin will check all according polices, like if a cluster 
attach two scaling-in polices, 
the two scaling-in polices will be checked when doing a scaling-action on this 
cluster. This is not same as  OS::Heat::ScalingPolicy in heat？
How should I use senlin for following cases？
1.  15% < cpu_util  < 30%,  scaling_in 1 instance
2.   cpu_util < 15%, scaling_in 2 instances

This is a very interesting question and you're right about the difference 
between Senlin ScalingPolicy and OS::Heat::ScalingPolicy. In Heat, 
OS::Heat::ScalingPolicy is actually not just a policy. It is a combination of a 
webhook and a rule about how ASG respond to the webhook triggering(resource 
signal). So you can define two different OS::Heat::ScalingPolicy instances to 
make them deal with two cases you described respectively.

But in Senlin, ScalingPolicy is a REAL policy, it only describes how a Senlin 
cluster react to an action triggered by Senlin webhook which is defined 
separately. The problem is when an cluster action e.g. CLUSTER_SCALE_IN is 
triggered, all policies attached to it will be checked in sequence based on 
policies priority definition. So if you create two Senlin ScalingPolicy and 
attach them to the same cluster, only one of them will take effect actually.

# 1.  But in policy_check function, all the policies will be checked in 
priority-based order for a CLUSTER_SCALING_IN action if the cluster attached 
with SCALING multiple policies. 
   is this a bug?  or  what  is the significance  of prority).  
Sorry, I didn't describe it clearly. I mean although both scaling 
policies will be checked before CLUSTER_SCALING_IN action is executed, count 
result from one ScalingPolicy will actually be overridden by the result from 
another ScalingPolicy which has higher priority. 
  
After debug it , I found thart former result is not overridden by another 
policy.
http://git.openstack.org/cgit/openstack/senlin/tree/senlin/engine/actions/base.py#n441
  
  
2. if  a cluster attached a scaling policy with event = CLUSTER_SCALE_IN,  
when a  CLUSTER_SCALING_OUT action is triggered,  the policy also will be 
checked,  is this reasonable?
 When a ScalingPolicy is defined, you can use 'event' property to 
specify the action type you want the policy to take effect on, like:
 
http://git.openstack.org/cgit/openstack/senlin/tree/examples/policies/scaling_policy.yaml#n5

 Although a ScalingPolicy will be checked for both CLUSTER_SCALE_IN and 
CLUSTER_SCALE_OUT actions, the check routine will return immediately if the 
action type is not what it is expecting. 
 
http://git.openstack.org/cgit/openstack/senlin/tree/senlin/policies/scaling_policy.py#n133

Yes in pre_op， it‘s not checked, but all ScalingPolicies still will check 
whether in cooldown.
http://git.openstack.org/cgit/openstack/senlin/tree/senlin/engine/actions/base.py#n431
 


Currently, you can use the following way to support your use case in Senlin:
1. Define two Senlin webhooks which target on the CLUSTER_SCALE_OUT action of 
the cluster and specify the 'param' as {'count': 1} for webhook1 and {'count': 
2 } for webhook2;
1. Define two ceilometer/aodh alarms with the first one matching case1 and 
second one matching case2. Then define webhook1 url as alarm1's alarm-action 
and webhook2 url as alarm2's alarm-action.

# 
Your suggestion has a problem when I want different cooldown for each 
ceilometer/aodh alarms, for following cases, how should I do?
1.  15% < cpu_util  < 30%,  scaling_in 1 instance with 300s cooldown time
2.   cpu_util < 15%, scaling_in 2 instances with 600s  cooldown time
 You can define the cooldown by specifying it when creating the policy or 
attaching it to a cluster. The cooldown check logic will prevent a policy 
taking effect if cooldown is still in progress.
 
http://git.openstack.org/cgit/openstack/senlin/tree/senlin/engine/actions/base.py#n431

Yes we can define cooldown for each policy, but I want each cluster_scaling_in 
action is only checked by one  scaling_policy like OS::Heat::ScalingPolicy?
In heat,  we could define two scaling_in actions(via define two  
OS::Heat::ScalingPolicy polices ), each scaling_in action is checked by one 
OS::Heat::ScalingPolicy, so each scaling_in action's cooldown is only checked 
in one OS::Heat::ScalingPolicy.
but in senlin, each scaling_in action will be checked by all attached 
scaling_policies, so all scaling_polices' cooldown will be checked.



For a senlin webhook, could we assign a policy 

[openstack-dev] [puppet] weekly meeting #60

[Emilien Macchi]

Hello!

Here's an initial agenda for our weekly meeting, Tuesday at 1500 UTC
in #openstack-meeting-4:

https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151124

Thanks,
-- 
Emilien Macchi



signature.asc
Description: OpenPGP digital signature
__
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] Fwd: [Senlin]Support more complicated scaling scenario

[Qiming Teng]

Hi,

  Please try quote previous responses in your message because it will
make the message a little bit easier to follow. You can set up your mail
client to do so. For example:

#
# 
#

Now this is your response

#
# 
#

When appropriate, you can even delete irrelevant texts when responding.
Just some suggestions.

p.s. you can stop by the #senlin channel to ask specific questions as
well.

Regards,
  Qiming


__
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] [openstack-ansible] Random ssh errors in gate check jobs

[Major Hayden]

Hey folks,

Some of my recent reviews have been frequent fliers in the land of CI gate jobs 
and I've spent a fair amount of time diagnosing random ssh failures to 
containers in AIO builds.  The error I get most often is this:

SSH Error: data could not be sent to the remote host. Make sure this host 
can be reached over ssh

After digging in Ansible code for a bit, I found the error within the ssh 
connection plugin[1].  It looks like an issue where the ssh connection is 
actually open but data cannot be sent to the subprocess.

I messed around heavily with multiplexing, keys, GSSAPI, and more, but the 
errors randomly appear.  I've proposed a review[2] for a switch to paramiko 
transport mode for gate jobs only and it has run four times without ssh errors 
(although two builds had timeouts due to the repo build taking too long).

The fifth build is running now and it seems to be moving along fairly quickly.

[1] 
https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/connection/ssh.py#L245-L260
[2] https://review.openstack.org/#/c/248361/

--
Major Hayden

__
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] [cinder][glance]Upload encrypted volumes to images

[Li, Xiaoyan]

Hi all,
More help about volume encryption is needed. 

About uploading encrypted volumes to image, there are three options:
1. Glance only keeps non-encrypted images. So when uploading encrypted volumes 
to image, cinder de-crypts the data and upload.
2. Glance maintain encrypted images. Cinder just upload the encrypted data to 
image. 
3. Just prevent the function to upload encrypted volumes to images.

Option 1 No changes needed in Glance. But it may be not safe. As we decrypt the 
data, and upload it to images. 
Option 2 This imports encryption to Glance which needs to manage the encryption 
metadata.

Please add more if you have other suggestions. How do you think which one is 
preferred.
Appreciate for your help.

Best wishes
Lisa



__
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] [cinder] [Sahara] Block Device Driver updates

[Zhidong Yu]

It seems there was a bug introduced in Kilo and then fixed in Liberty [6].
However, since there are more users of Kilo than of Liberty, I am wondering
if the fix has been back ported to Kilo. I could not find it except for
this one [7] which seems to be a different issue.

[6] https://review.openstack.org/#/c/200039/
[7] https://bugs.launchpad.net/cinder/+bug/1465819

On Thu, Oct 1, 2015 at 3:00 AM, Ivan Kolodyazhny  wrote:

> Hi team,
>
> I know that Block Device Driver (BDD) is not popular in Cinder community.
> The main issues were:
>
> * driver is not good maintained
> * it doesn't feet minimum features set
> * there is no CI for it
> * it's not a Cinder way/it works only when instance and volume are created
> on the same host
> * etc
>
> AFAK, it's widely used in Sahara &  Hadoop communities because it works
> fast. I won't discuss driver's performance in this thread. I share my
> performance tests results once I'll finish it.
>
> I'm going to share drive updates with you about issues above.
>
> 1) driver is not good maintained - we are working on it right now and will
> fix any found issues. We've got devstack plugin [1] for this driver.
>
> 2) it doesn't feet minimum features set - I've filed a blueprint [2] for
> it. There are patches that implement needed features in the gerrit [3].
>
> 3) there is no CI for it - In Cinder community, we've got strong
> requirement that each driver must has CI. I've absolutely agree with that.
> That's why new infra job is proposed [4].
>
> 4) it works only when instance and volume are created on the same host -
> I've filed a blueprint [5] but after testing I've found that it's already
> implemented by [6].
>
>
> I hope, I've answered all questions that were asked in IRC and in comments
> for [6]. I will do my best to support this driver and propose fix to delete
> if community decide  to delete it from the cinder tree
>
>
> [1] https://github.com/openstack/devstack-plugin-bdd
> [2]
> https://blueprints.launchpad.net/cinder/+spec/block-device-driver-minimum-features-set
> [3]
> https://review.openstack.org/#/q/status:open+project:openstack/cinder+branch:master+topic:bp/block-device-driver-minimum-features-set,n,z
> [4] https://review.openstack.org/228857
> [5]
> https://blueprints.launchpad.net/cinder/+spec/block-device-driver-via-iscsi
> [6] https://review.openstack.org/#/c/200039/
>
>
> Regards,
> Ivan Kolodyazhny
>
> __
> 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] Fwd: [Senlin]Support more complicated scaling scenario

[Yanyan Hu]

Hi, Xu Jun, please find some answers inline. Thanks.


2015-11-20 16:06 GMT+08:00 xu...@cmss.chinamobile.com <
xu...@cmss.chinamobile.com>:

> Thanks yanyan!
>
> Xu Jun is a contributor from CMCC. He asked a very interesting question
> about cluster scaling support in Senlin. To make the discussion more
> thorough, I just post the question and my answer here.
>
> The question from Jun is as following:
>
> For an action, senlin will check all according polices, like if a cluster
> attach two scaling-in polices,
> the two scaling-in polices will be checked when doing a scaling-action on
> this cluster. This is not same as  OS::Heat::ScalingPolicy in heat？
> How should I use senlin for following cases？
> 1.  15% < cpu_util  < 30%,  scaling_in 1 instance
> 2.   cpu_util < 15%, scaling_in 2 instances
>
> This is a very interesting question and you're right about the difference
> between Senlin ScalingPolicy and OS::Heat::ScalingPolicy. In Heat,
> OS::Heat::ScalingPolicy is actually not just a policy. It is a combination
> of a webhook and a rule about how ASG respond to the webhook
> triggering(resource signal). So you can define two different
> OS::Heat::ScalingPolicy instances to make them deal with two cases you
> described respectively.
>
> But in Senlin, ScalingPolicy is a REAL policy, it only describes how a
> Senlin cluster react to an action triggered by Senlin webhook which is
> defined separately. The problem is when an cluster action e.g.
> CLUSTER_SCALE_IN is triggered, all policies attached to it will be checked
> in sequence based on policies priority definition. *So if you create two
> Senlin ScalingPolicy and attach them to the same cluster, only one of them
> will take effect actually.*
>
> # 1.  But in policy_check function, all the policies will be checked in
> priority-based order for a CLUSTER_SCALING_IN action if the cluster
> attached with SCALING multiple policies.
>is this a bug?  or  what  is the significance  of prority).
>
> *Sorry, I didn't describe it clearly. I mean although both
scaling policies will be checked before CLUSTER_SCALING_IN action is
executed, count result from one ScalingPolicy will actually be overridden
by the result from another ScalingPolicy which has higher priority. *


> 2. if  a cluster attached a scaling policy with event = CLUSTER_SCALE_IN,
>  when a  CLUSTER_SCALING_OUT action is triggered,  the policy also will
> be checked,  is this reasonable?
>
>



* When a ScalingPolicy is defined, you can use 'event' property to
specify the action type you want the policy to take effect on,
like:
http://git.openstack.org/cgit/openstack/senlin/tree/examples/policies/scaling_policy.yaml#n5

Although a ScalingPolicy will be checked for both CLUSTER_SCALE_IN and
CLUSTER_SCALE_OUT actions, the check routine will return immediately if the
action type is not what it is expecting.
http://git.openstack.org/cgit/openstack/senlin/tree/senlin/policies/scaling_policy.py#n133
*

>
>
> Currently, you can use the following way to support your use case in
> Senlin:
> 1. Define two Senlin webhooks which target on the CLUSTER_SCALE_OUT action
> of the cluster and specify the 'param' as {'count': 1} for webhook1 and
> {'count': 2 } for webhook2;
> 1. Define two ceilometer/aodh alarms with the first one matching case1 and
> second one matching case2. Then define webhook1 url as alarm1's
> alarm-action and webhook2 url as alarm2's alarm-action.
>
> #
> Your suggestion has a problem when I want different cooldown for each
> ceilometer/aodh alarms, for following cases, how should I do?
> 1.  15% < cpu_util  < 30%,  scaling_in 1 instance with 300s cooldown time
> 2.   cpu_util < 15%, scaling_in 2 instances with 600s  cooldown time
>
>

* You can define the cooldown by specifying it when creating the policy
or attaching it to a cluster. The cooldown check logic will prevent a
policy taking effect if cooldown is still in progress.
http://git.openstack.org/cgit/openstack/senlin/tree/senlin/engine/actions/base.py#n431
*

>
> For a senlin webhook, could we assign a policy which will be checked ?
>
>  *User is not allowed to specify the policy when defining a webhook.
The webhook target is decided by target object(cluster or node) and target
action type.*

>
> Then each time alarm1 is triggered, cluster will be scaled out with count
> 1 which means one new node will be created and added to cluster. When
> alarm2 is triggered, cluster will be scaled out with count 2 that two new
> nodes will be created and added to cluster.
>
> The question you asked is really interesting and we did consider to
> support this kind of requirement using a 'complex' ScalingPolicy which
> defined both 

Re: [openstack-dev] [Senlin]Support more complicated scaling scenario

[jun.xu...@139.com]

Thanks yanyan!

Xu Jun is a contributor from CMCC. He asked a very interesting question about 
cluster scaling support in Senlin. To make the discussion more thorough, I just 
post the question and my answer here.

The question from Jun is as following:

For an action, senlin will check all according polices, like if a cluster 
attach two scaling-in polices, 
the two scaling-in polices will be checked when doing a scaling-action on this 
cluster. This is not same as  OS::Heat::ScalingPolicy in heat？
How should I use senlin for following cases？
1.  15% < cpu_util  < 30%,  scaling_in 1 instance
2.   cpu_util < 15%, scaling_in 2 instances

This is a very interesting question and you're right about the difference 
between Senlin ScalingPolicy and OS::Heat::ScalingPolicy. In Heat, 
OS::Heat::ScalingPolicy is actually not just a policy. It is a combination of a 
webhook and a rule about how ASG respond to the webhook triggering(resource 
signal). So you can define two different OS::Heat::ScalingPolicy instances to 
make them deal with two cases you described respectively.

But in Senlin, ScalingPolicy is a REAL policy, it only describes how a Senlin 
cluster react to an action triggered by Senlin webhook which is defined 
separately. The problem is when an cluster action e.g. CLUSTER_SCALE_IN is 
triggered, all policies attached to it will be checked in sequence based on 
policies priority definition. So if you create two Senlin ScalingPolicy and 
attach them to the same cluster, only one of them will take effect actually.

# 1.  But in policy_check function, all the policies will be checked in 
priority-based order for a CLUSTER_SCALING_IN action if the cluster attached 
with SCALING multiple policies. 
   is this a bug?  or  what  is the significance  of prority).  
2. if  a cluster attached a scaling policy with event = CLUSTER_SCALE_IN,  
when a  CLUSTER_SCALING_OUT action is triggered,  the policy also will be 
checked,  is this reasonable?

Currently, you can use the following way to support your use case in Senlin:
1. Define two Senlin webhooks which target on the CLUSTER_SCALE_OUT action of 
the cluster and specify the 'param' as {'count': 1} for webhook1 and {'count': 
2 } for webhook2;
1. Define two ceilometer/aodh alarms with the first one matching case1 and 
second one matching case2. Then define webhook1 url as alarm1's alarm-action 
and webhook2 url as alarm2's alarm-action.

# 
Your suggestion has a problem when I want different cooldown for each 
ceilometer/aodh alarms, for following cases, how should I do?
1.  15% < cpu_util  < 30%,  scaling_in 1 instance with 300s cooldown time
2.   cpu_util < 15%, scaling_in 2 instances with 600s  cooldown time

For a senlin webhook,  could we assign a policy which will be checked ?

Then each time alarm1 is triggered, cluster will be scaled out with count 1 
which means one new node will be created and added to cluster. When alarm2 is 
triggered, cluster will be scaled out with count 2 that two new nodes will be 
created and added to cluster.

The question you asked is really interesting and we did consider to support 
this kind of requirement using a 'complex' ScalingPolicy which defined both 
trigger(alarm), webhook and some rules for scaling. But after some discussion, 
we felt that maybe we should let some high level service/enduser to define this 
kind of 'POLICY' since it's more like a workflow definition rather than a 
description of the rule cluster scaling. So currently, we only provide atomic 
operation(e.g. webhook, 'simple' ScalingPolicy) in Senlin while leaving the 
work of combining these operations to support a use case to enduser/high-level 
service.

Thanks a lot for throwing this interesting question and I do agree that we 
should make more discussion about it to think whether we need to adjust our 
policy design to support this kind of scenario more smoothly.

--
Best regards,

Yanyan
__
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] [devstack] How to source openrc?

[Wilence Yao]

Hi all,

In devstack stable/liberty, error is :

source openrc admin admin
openrc:90: unknown condition: -v

the line 90 and code block in openrc is
```
# Set OS_CACERT to a default CA certificate chain if it exists.
if [[ ! -v OS_CACERT ]] ; then
DEFAULT_OS_CACERT=$INT_CA_DIR/ca-chain.pem
# If the file does not exist, this may confuse preflight sanity checks
if [ -e $DEFAULT_OS_CACERT ] ; then
export OS_CACERT=$DEFAULT_OS_CACERT
fi
fi
```
So how to source devstack/openrc ? What command it is ?

Wilence
__
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][ThirdPartyCI] Running third party CI on networking-foo projects

[fumihiko kakuma]

Hi Fawad,

I am sorry for the late reply.

On Fri, 20 Nov 2015 12:26:05 +0900
Takashi Yamamoto  wrote:

> On Fri, Nov 20, 2015 at 2:27 AM, Fawad Khaliq  wrote:
> > Thanks a lot, Yamamoto.
> >
> > kakuma, I am assuming if you were able to set it up for a ofagent repo, then
> > it should have been the standard procedure documented here [1]. I reach out
> > to infra for any help.
> >
> > [1] http://docs.openstack.org/infra/system-config/third_party.html
> >

I also don't know the standard document other than it.

> > Fawad Khaliq
> 
> here's an instruction in case you can read japanese. :-)
> https://github.com/osrg/ryu-neutron-zuul-ci/blob/master/doc/install.ja.txt
> 

The updated document for the above can be found from the following URL.
(That also is only japanese.)
https://github.com/osrg/ofaci-inst/blob/master/docs/install.ja.txt

But I don't try the procedure since installed in environment for juno.
It may not work well, because infra repository had big change.

I also refered to the following pages
(but they don't seem to be updated).

http://www.joinfu.com/2014/02/setting-up-an-external-openstack-testing-system/
http://www.joinfu.com/2014/02/setting-up-an-openstack-external-testing-system-part-2/

You may also obtain any information about CI attending at the thirdparty 
meeting.

https://wiki.openstack.org/wiki/Meetings/ThirdParty

On the other hand if you only want to run CI for the change to your project,
you should add project-config/jenkins/jobs/networking-prumgrid.yaml.
For eaxample, like https://review.openstack.org/#/c/198740/


> >
> >
> > On Wed, Nov 18, 2015 at 9:03 AM, Takashi Yamamoto 
> > wrote:
> >>
> >> hi,
> >>
> >> On Wed, Nov 18, 2015 at 2:00 AM, Fawad Khaliq  wrote:
> >> > Folks,
> >> >
> >> > What would be the mechanism to enable a third party CI on a Neutron
> >> > sub-project? I am not sure if anyone has already tried it.
> >>
> >> networking-ofagent has its third party CI running.
> >> you can ask kakuma for details.
> >>
> >> >
> >> > I am interesting in adding PLUMgrid CI on networking-plumgrid [1]
> >> >
> >> > cc: Mike
> >> >
> >> > [1] https://github.com/openstack/networking-plumgrid
> >> >
> >> > Thanks,
> >> > Fawad Khaliq
> >> >
> >> >
> >> >
> >> > __
> >> > 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

-- 
fumihiko kakuma 



__
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] [kolla] Proposing Michal Rostecki for Core Reviewer (nihilfer on IRC)

[Steven Dake (stdake)]

Michal,

Welcome to the Kolla core team.  My apologies for being past deadline I set of 
the 20th, dealing with some personal issues related to children and wife 
traveling and -toomuchinput.

Regards
-steve


From: Steven Dake >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Thursday, November 12, 2015 at 1:41 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [kolla] Proposing Michal Rostecki for Core Reviewer 
(nihilfer on IRC)

Hey folks,

Its been awhile since we have had a  core reviewer nomination, but I really 
feel like Michal has the right stuff.  If you look at the 30 day stats for 
kolla[1] , he is #3 in reviews (70 reviews) with 6 commits in a 30 day period.  
He is beating 2/3rds of our core reviewer team on all stats.  I think his 
reviews, while could use a little more depth, are solid and well considered.  
That said he participates on the mailing list more then others and has been 
very active in IRC.  He has come up to speed on the code base in quick order 
and I expect if he keeps pace, the top reviewers in Kolla will be challenged to 
maintain their spots :)  Consider this proposal as a +1 vote from me.

As a reminder, our core review process requires 3 core reviewer +1 votes, with 
no core reviewer -1 (veto) votes within a 1 week period.  If your on the fence, 
best to abstain :)  I'll close voting November 20th, or sooner if there I a 
veto vote or a unanimous vote.

Regards
-steve

http://stackalytics.com/report/contribution/kolla-group/30
__
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
 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] [nova] FKs in the DB

[Mike Bayer]

On 11/20/2015 04:33 PM, Clint Byrum wrote:
> Excerpts from Mike Bayer's message of 2015-11-20 11:29:31 -0800:
>>
>> On 11/20/2015 11:19 AM, Alexis Lee wrote:
>>> We just had a fun discussion in IRC about whether foreign keys are evil.
>>> Initially I thought this was crazy but mordred made some good points. To
>>> paraphrase, that if you have a scale-out app already it's easier to
>>> manage integrity in your app than scale-out your persistence layer.
>>
>> I've had this argument with mordred before, and it seems again there's
>> the same misunderstanding going on:
>>
>> 1. Your application can have **conceptual** foreign keys in it, without
>> actually having foreign keys **for real** in the database.  This means
>> your SQLAlchemy code still does ForeignKey, ForeignKeyConstraint, and
>> most importantly your **database still uses normal form**, that is, any
>> row that refers to another does it based on a set of columns that
>> exactly match to the primary key of a single table elsewhere (not to
>> multiple tables, not to a function of the columns cast from int to
>> string and concatenated to the value in the other table etc, an *exact
>> match*).   I'm sure that mordred agrees with all of these practices,
>> however when one says "we aren't going to use foreign keys anymore",
>> typically it is all these critical schema design practices that go out
>> the window.  Put another way, the foreign key concept not only
>> constrains data in a real database, just the concept of them constraints
>> the **developer** to use correct normal form.
>>
> 
> Mike, thanks for making that clarification. I agree, that conceptual
> FK's are not the same as FK constraints in the DB. Joins are not demons.
> :)
> 
> To be clear, while what you say above is all true, normal form isn't
> actually a goal of any system. It's a tactic one can use with a well known
> efficiency profile. But there are times when it costs more than other
> more brutal, less civilized methods of database design and usage. If we
> don't measure our efficiency, we won't actually know if this is one of
> those times or not.


Hi Clint -

To be clear to be clear (  :)  ), I am absolutely fine with:

1. disabling particular foreign key constraints on the server that are
shown to be a performance bottleneck

2. using denormalized forms where appropriate


My only point is, the *starting position* for any new database construct
should be favoring reasonable normalized forms and foreign key
constraints, with disabled constraints and denormalized forms the
exceptions, when shown to be appropriate.

What I don't want is, "we don't use foreign keys, they suck", and you
then see the growth of all the wacky unmaintainable schema designs we
see all the time in the PHP world and to some degree the ROR world -
straight up incorrect designs, which as I mentioned earlier, include
things like a series of columns related to another one only via some
series of functions like string concatenations and casts, so-called
"polymorphic foreign keys" where a particular column matches to that of
a row in any one of several other tables, etc.   My userbase in the
SQLAlchemy world is always coming to me with, "I have this terrible
legacy schema design where" and then they have something like this
going on which they're struggling to work around.

Perhaps my point is, if we make a blanket "we don't use foreign keys"
statement, then you just lift one of the last beachheads we have against
folks who just don't know what they're doing implementing unmaintainable
database designs.   Hence I think the FK concept should remain important
and central when we work with relational schema design in Openstack,
subject to exceptions as appropriate on a case-by-case basis.



> 
>> 2. Here's the part mordred doesn't like - the FK is actually in the
>> database for real.   This is because they slow down inserts, updates,
>> and deletes, because they must be checked.   To which I say, no such
>> performance issue has been observed or documented in Openstack, we
>> aren't a 1 million TPS financial system, so this is vastly premature
>> optimization.
>>
> 
> I agree with you that this is unmeasured. I don't agree that we are not a
> 1 million TPS financial system, because the goal of running a cloud for
> many is, in fact, to make money. So while we may not have an example of
> a cloud running at 1 million TPS, it's not something we should dismiss
> too quickly.
> 
> That said, the measurement should come first. What I'd like to show
> is how many TPS we do actually do on boots, deletes, etc. etc. I'm
> working on it now, and I'd encourage people to join the effort on the
> counter-inspection QA spec if they want to get started measuring things.
> We're taking baby steps right now, but eventually I see us producing a
> lot of data that should be helpful in answering some of these questions.
> 
>> Also as far as #2, customers and operators *regularly* run scripts and
>> queries to modify 

Re: [openstack-dev] [Neutron] Security Groups OVS conntrack support

[Gal Sagie]

Hi Fawad,

>From what i could understand from Miguel Angel Ajo, someone is working on
this integration and it
is suppose to be delivered as part of Mitaka.
I don't remember the person name, Miguel will sure update shortly.

Gal.

On Sun, Nov 22, 2015 at 7:05 PM, Fawad Khaliq  wrote:

> Folks,
>
> Is there a plan to add conntrack support to the security groups for the
> OVS driver in Mitaka cycle?
>
> My understanding is that it is being actively worked on for networking-ovn
> but no concrete plan for support in the OVS Neutron driver yet.
>
> Thanks,
> Fawad Khaliq
>
>
> __
> 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 ,

The G.
__
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] [Neutron] Security Groups OVS conntrack support

[Fawad Khaliq]

Folks,

Is there a plan to add conntrack support to the security groups for the OVS
driver in Mitaka cycle?

My understanding is that it is being actively worked on for networking-ovn
but no concrete plan for support in the OVS Neutron driver yet.

Thanks,
Fawad Khaliq
__
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] [kolla] Proposing Michal Rostecki for Core Reviewer (nihilfer on IRC)

[Michal Rostecki]

On 11/22/2015 04:17 PM, Steven Dake (stdake) wrote:

Michal,

Welcome to the Kolla core team.  My apologies for being past deadline I
set of the 20th, dealing with some personal issues related to children
and wife traveling and –toomuchinput.

Regards
-steve



Thank you for the nomination and votes! I'm glad to work with all of you 
on kolla and to be a part of such great community.


Regards,
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