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

2015-11-19 Thread Endre Karlson
Regarding tunnel for that. How do you ensure packet timestamps and
ordering?

Endre Karlson
19. nov. 2015 4.55 a.m. skrev "Li Ma" <skywalker.n...@gmail.com>:

> 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
> <shigeta.soi...@jp.fujitsu.com> 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] Quota management and enforcement across projects

2014-11-19 Thread Endre Karlson
All I can say at the moment is that Usage and Quota management is a crappy
thing to do in OpenStack. Every service has it's own way of doing it both
in clients and api's. +n+ for making a effort in standardizing this thing
in a way that could be alike across projects..

2014-11-19 14:33 GMT+01:00 Sylvain Bauza sba...@redhat.com:


 Le 18/11/2014 20:05, Doug Hellmann a écrit :

  On Nov 17, 2014, at 7:18 PM, Kevin L. Mitchell 
 kevin.mitch...@rackspace.com wrote:

  On Mon, 2014-11-17 at 18:48 -0500, Doug Hellmann wrote:

 I’ve spent a bit of time thinking about the resource ownership issue.
 The challenge there is we don’t currently have any libraries that
 define tables in the schema of an application. I think that’s a good
 pattern to maintain, since it avoids introducing a lot of tricky
 issues like how to manage migrations for the library, how to ensure
 they are run by the application, etc. The fact that this common quota
 thing needs to store some data in a schema that it controls says to me
 that it is really an app and not a library. Making the quota manager
 an app solves the API definition issue, too, since we can describe a
 generic way to configure quotas and other applications can then use
 that API to define specific rules using the quota manager’s API.

 I don’t know if we need a new application or if it would make sense
 to, as with policy, add quota management features to keystone. A
 single well-defined app has some appeal, but there’s also a certain
 amount of extra ramp-up time needed to go that route that we wouldn’t
 need if we added the features directly to keystone.

 I'll also point out that it was largely because of the storage needs
 that I chose to propose Boson[1] as a separate app, rather than as a
 library.  Further, the dimensions over which quota-covered resources
 needed to be tracked seemed to me to be complicated enough that it would
 be better to define a new app and make it support that one domain well,
 which is why I didn't propose it as something to add to Keystone.
 Consider: nova has quotas that are applied by user, other quotas that
 are applied by tenant, and even some quotas on what could be considered
 sub-resources—a limit on the number of security group rules per security
 group, for instance.

 My current feeling is that, if we can figure out a way to make the quota
 problem into an acceptable library, that will work; it would probably
 have to maintain its own database separate from the client app and have
 features for automatically managing the schema, since we couldn't
 necessarily rely on the client app to invoke the proper juju there.  If,
 on the other hand, that ends up failing, then the best route is probably
 to begin by developing a separate app, like Boson, as a PoC; then, after
 we have some idea of just how difficult it is to actually solve the
 problem, we can evaluate whether it makes sense to actually fold it into
 a service like Keystone, or whether it should stand on its own.

 (Personally, I think Boson should be created and should stand on its
 own, but I also envision using it for purposes outside of OpenStack…)

 Thanks for mentioning Boson again. I’m embarrassed that I completely
 forgot about the fact that you mentioned this at the summit.

 I’ll have to look at the proposal more closely before I comment in any
 detail, but I take it as a good sign that we’re coming back around to the
 idea of solving this with an app instead of a library.


 I assume I'm really late in the thread so I can just sit and give +1 to
 this direction : IMHO, quotas need to managed thanks to a CRUD interface
 which implies to get an app, as it sounds unreasonable to extend each
 consumer app API.

 That said, back to Blazar, I just would like to emphasize that Blazar is
 not trying to address the quota enforcement level, but rather provide a
 centralized endpoint for managing reservations.
 Consequently, Blazar can also be considered as a consumer of this quota
 system, whatever it's in a library or on a separate REST API.

 Last thing, I don't think that a quota application necessarly means that
 quotas enforcement should be managed thanks to external calls to this app.
 I can rather see an external system able to set for each project a local
 view of what should be enforced locally. If operators don't want to deploy
 that quota management project, it's up to them to address the hetergenous
 setups for each project.

 My 2 cts (too),
 -Sylvain


  Doug

  Just my $.02…

 [1] https://wiki.openstack.org/wiki/Boson
 --
 Kevin L. Mitchell kevin.mitch...@rackspace.com
 Rackspace


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 

Re: [openstack-dev] oslo.db 1.1.0 released

2014-11-18 Thread Endre Karlson
Not sure if relevant but some tests on changes to requirements where
failing today too on the postgres job

Endre Karlson
Matt,

This is really weird. Victor and I will take a closer look.

Thanks,
Roman

On Tue, Nov 18, 2014 at 5:22 AM, Matt Riedemann
mrie...@linux.vnet.ibm.com wrote:


 On 11/17/2014 9:36 AM, Victor Sergeyev wrote:

 Hello All!

 Oslo team is pleased to announce the new release of Oslo database
 handling library - oslo.db 1.1.0

 List of changes:
 $ git log --oneline --no-merges  1.0.2..master
 1b0c2b1 Imported Translations from Transifex
 9aa02f4 Updated from global requirements
 766ff5e Activate pep8 check that _ is imported
 f99e1b5 Assert exceptions based on API, not string messages
 490f644 Updated from global requirements
 8bb12c0 Updated from global requirements
 4e19870 Reorganize DbTestCase to use provisioning completely
 2a6dbcd Set utf8 encoding for mysql and postgresql
 1b41056 ModelsMigrationsSync: Add check for foreign keys
 8fb696e Updated from global requirements
 ba4a881 Remove extraneous vim editor configuration comments
 33011a5 Remove utils.drop_unique_constraint()
 64f6062 Improve error reporting for backend import failures
 01a54cc Ensure create_engine() retries the initial connection test
 26ec2fc Imported Translations from Transifex
 9129545 Use fixture from oslo.config instead of oslo-incubator
 2285310 Move begin ping listener to a connect listener
 7f9f4f1 Create a nested helper function that will work on py3.x
 b42d8f1 Imported Translations from Transifex
 4fa3350 Start adding a environment for py34/py33
 b09ee9a Explicitly depend on six in requirements file
 7a3e091 Unwrap DialectFunctionDispatcher from itself.
 0928d73 Updated from global requirements
 696f3c1 Use six.wraps instead of functools.wraps
 8fac4c7 Update help string to use database
 fc8eb62 Use __qualname__ if we can
 6a664b9 Add description for test_models_sync function
 8bc1fb7 Use the six provided iterator mix-in
 436dfdc ModelsMigrationsSync:add correct server_default check for Enum
 2075074 Add history/changelog to docs
 c9e5fdf Add run_cross_tests.sh script

 Thanks Andreas Jaeger, Ann Kamyshnikova, Christian Berendt, Davanum
 Srinivas, Doug Hellmann, Ihar Hrachyshka, James Carey, Joshua Harlow,
 Mike Bayer, Oleksii Chuprykov, Roman Podoliaka for contributing to this
 release.

 Please report issues to the bug tracker:
 https://bugs.launchpad.net/oslo.db


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 And...the nova postgresql opportunistic DB tests are failing quite
 frequently due to some race introduced by the new library version [1].

 [1] https://bugs.launchpad.net/oslo.db/+bug/1393633

 --

 Thanks,

 Matt Riedemann



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all] [clients] [keystone] lack of retrying tokens leads to overall OpenStack fragility

2014-09-10 Thread Endre Karlson
I think at least clients supporting keystone sessions that are configured
to use the auth.Password mech supports this since re-auth is done by the
session rather then the service client itself.

2014-09-10 16:14 GMT+02:00 Sean Dague s...@dague.net:

 Going through the untriaged Nova bugs, and there are a few on a similar
 pattern:

 Nova operation in progress takes a while
 Crosses keystone token expiration time
 Timeout thrown
 Operation fails
 Terrible 500 error sent back to user

 It seems like we should have a standard pattern that on token expiration
 the underlying code at least gives one retry to try to establish a new
 token to complete the flow, however as far as I can tell *no* clients do
 this.

 I know we had to add that into Tempest because tempest runs can exceed 1
 hr, and we want to avoid random fails just because we cross a token
 expiration boundary.

 Anyone closer to the clients that can comment here?

 -Sean

 --
 Sean Dague
 http://dague.net

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] What does NASA not using OpenStack mean to OS's future

2014-08-25 Thread Endre Karlson
1. If you're wanting to start a fire you need to somewhere else then a
development mailing list.
2. Get your facts together, much of what you're writing on Quota as many
has pointed out is totally wrong.

Also what Anita noted earlier about OS != OpenStack in that sense.

Please keep topics like this off the ML.

Regards
Endre



2014-08-25 18:48 GMT+02:00 Aryeh Friedman aryeh.fried...@gmail.com:

 1. Sorry wrong list
 2. Your answers just confirm NASA was right


 On Mon, Aug 25, 2014 at 12:22 PM, Steve Martinelli steve...@ca.ibm.com
 wrote:

 This is hardly a development related question.


 Regards,

 *Steve Martinelli*
 Software Developer - OpenStack
 Keystone Core Member
 --
  *Phone:* 1-905-413-2851
 * E-mail:* *steve...@ca.ibm.com* steve...@ca.ibm.com
 8200 Warden Ave
 Markham, ON L6G 1C7
 Canada



 Aryeh Friedman aryeh.fried...@gmail.com wrote on 08/25/2014 12:08:50
 PM:

  From: Aryeh Friedman aryeh.fried...@gmail.com
  To: OpenStack Development Mailing List (not for usage questions)
  openstack-dev@lists.openstack.org,
  Date: 08/25/2014 12:12 PM
  Subject: [openstack-dev] What does NASA not using OpenStack mean to
  OS's future
 
  http://www.quora.com/Why-would-the-creators-of-OpenStack-the-market-

  leader-in-cloud-computing-platforms-refuse-to-use-it-and-use-AWS-instead
 
  --
  Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
 http://www.petitecloud.org/

  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [neutron][all] switch from mysqldb to another eventlet aware mysql client

2014-08-21 Thread Endre Karlson
Why pymysql over mysql-python?

Endre Karlson
21. Aug. 2014 09:05 skrev Angus Lees g...@inodes.org følgende:

 On Wed, 20 Aug 2014 05:03:51 PM Clark Boylan wrote:
  On Mon, Aug 18, 2014, at 01:59 AM, Ihar Hrachyshka wrote:
   -BEGIN PGP SIGNED MESSAGE-
   Hash: SHA512
  
   On 17/08/14 02:09, Angus Lees wrote:
On 16 Aug 2014 06:09, Doug Hellmann d...@doughellmann.com
   
mailto:d...@doughellmann.com wrote:
On Aug 15, 2014, at 9:29 AM, Ihar Hrachyshka
ihrac...@redhat.com
   
mailto:ihrac...@redhat.com wrote:
Signed PGP part Some updates on the matter:
   
- oslo-spec was approved with narrowed scope which is now
'enabled mysqlconnector as an alternative in gate' instead of
'switch the default db driver to mysqlconnector'. We'll revisit
the switch part the next cycle once we have the new driver
running in gate and real benchmarking is heavy-lifted.
   
- there are several patches that are needed to make devstack
and tempest passing deployment and testing. Those are collected
under the hood of: https://review.openstack.org/#/c/114207/ Not
much of them.
   
- we'll need a new oslo.db release to bump versions (this is
needed to set raise_on_warnings=False for the new driver, which
was incorrectly set to True in sqlalchemy till very recently).
This is expected to be released this month (as per Roman
Podoliaka).
   
This release is currently blocked on landing some changes in
projects
   
using the library so they don?t break when the new version starts
using different exception classes. We?re tracking that work in
https://etherpad.openstack.org/p/sqla_exceptions_caught
   
It looks like we?re down to 2 patches, one for cinder
   
(https://review.openstack.org/#/c/111760/) and one for glance
(https://review.openstack.org/#/c/109655). Roman, can you verify
that those are the only two projects that need changes for the
exception issue?
   
- once the corresponding patch for sqlalchemy-migrate is
merged, we'll also need a new version released for this.
   
So we're going for a new version of sqlalchemy?  (We have a
separate workaround for raise_on_warnings that doesn't require the
new sqlalchemy release if this brings too many other issues)
  
   Wrong. We're going for a new version of *sqlalchemy-migrate*. Which is
   the code that we inherited from Mike and currently track in stackforge.
  
- on PyPI side, no news for now. The last time I've heard from
Geert (the maintainer of MySQL Connector for Python), he was
working on this. I suspect there are some legal considerations
running inside Oracle. I'll update once I know more about
that.
   
If we don?t have the new package on PyPI, how do we plan to
include it
   
in the gate? Are there options to allow an exception, or to make
the mirroring software download it anyway?
   
We can test via devstack without waiting for pypi, since devstack
will install via rpms/debs.
  
   I expect that it will be settled. I have no indication that the issue
   is unsolvable, it will just take a bit more time than we're accustomed
   to. :)
  
   At the moment, we install MySQLdb from distro packages for devstack.
   Same applies to new driver. It will be still great to see the package
   published on PyPI so that we can track its version requirements
   instead of relying on distros to package it properly. But I don't see
   it as a blocker.
  
   Also, we will probably be able to run with other drivers supported by
   SQLAlchemy once all the work is done.
 
  So I got bored last night and decided to take a stab at making PyMySQL
  work since I was a proponent of it earlier. Thankfully it did just
  mostly work like I thought it would.
  https://review.openstack.org/#/c/115495/ is the WIP devstack change to
  test this out.

 Thanks!

  Postgres tests fail because it was applying the pymysql driver to the
  postgres connection string. We can clean this up later in devstack
  and/or devstack-gate depending on how we need to apply this stuff.
  Bashate failed because I had to monkeypatch in a fix for a ceilometer
  issue loading sqlalchemy drivers. The tempest neutron full job fails on
  one test occasionally. Not sure yet if that is normal neutron full
  failure mode or if a new thing from PyMySQL. The regular tempest job
  passes just fine.
 
  There are also some DB related errors in the logs that will need to be
  cleaned up but overall it just works. So I would like to repropose that
  we stop focusing all of this effort on the hard thing and use the easy
  thing if it meets our needs. We can continue to make alternatives work,
  but that is a different problem that we can solve at a different pace. I
  am not sure how to test the neutron thing that Gus was running into
  though so we should also check that really quickly.

 TL;DR: pymysql passes my test case.
 I'm perfectly happy to move

Re: [openstack-dev] introducing cyclops

2014-08-07 Thread Endre Karlson
Hi, are you on IRC? :)

Endre


2014-08-07 12:01 GMT+02:00 Piyush Harsh h...@zhaw.ch:

 Dear All,

 Let me use my first post to this list to introduce Cyclops and initiate a
 discussion towards possibility of this platform as a future incubated
 project in OpenStack.

 We at Zurich university of Applied Sciences have a python project in open
 source (Apache 2 Licensing) that aims to provide a platform to do
 rating-charging-billing over ceilometer. We call is Cyclops (A Charging
 platform for OPenStack CLouds).

 The initial proof of concept code can be accessed here:
 https://github.com/icclab/cyclops-web 
 https://github.com/icclab/cyclops-tmanager

 *Disclaimer: This is not the best code out there, but will be refined and
 documented properly very soon!*

 A demo video from really early days of the project is here:
 https://www.youtube.com/watch?v=ZIwwVxqCio0 and since this video was
 made, several bug fixes and features were added.

 The idea presentation was done at Swiss Open Cloud Day at Bern and the
 talk slides can be accessed here:
 http://piyush-harsh.info/content/ocd-bern2014.pdf, and more recently the
 research paper on the idea was published in 2014 World Congress in Computer
 Science (Las Vegas), which can be accessed here:
 http://piyush-harsh.info/content/GCA2014-rcb.pdf

 I was wondering, if our effort is something that OpenStack
 Ceilometer/Telemetry release team would be interested in?

 I do understand that initially rating-charging-billing service may have
 been left out by choice as they would need to be tightly coupled with
 existing CRM/Billing systems, but Cyclops design (intended) is distributed,
 service oriented architecture with each component allowing for possible
 integration with external software via REST APIs. And therefore Cyclops by
 design is CRM/Billing platform agnostic. Although Cyclops PoC
 implementation does include a basic bill generation module.

 We in our team are committed to this development effort and we will have
 resources (interns, students, researchers) work on features and improve the
 code-base for a foreseeable number of years to come.

 Do you see a chance if our efforts could make in as an incubated project
 in OpenStack within Ceilometer?

 I really would like to hear back from you, comments, suggestions, etc.

 Kind regards,
 Piyush.
 ___
 Dr. Piyush Harsh, Ph.D.
 Researcher, InIT Cloud Computing Lab
 Zurich University of Applied Sciences (ZHAW)
 [Site] http://piyush-harsh.info
 [Research Lab] http://www.cloudcomp.ch/
 Fax: +41(0)58.935.7403 GPG Keyid: 9C5A8838

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] What projects need help?

2014-07-09 Thread Endre Karlson
Designate too ! We need address / phone ish book for OpenStack ;)


2014-07-09 9:51 GMT+02:00 Flavio Percoco fla...@redhat.com:

 On 07/09/2014 04:31 AM, Brian Jarrett wrote:
  Developers,
 
  I'm looking to become a contributor.  I've already signed the CLA, etc.
  and I'm looking through tons of documentation, but I'm thinking it might
  be good to have a project I could focus on.
 
  Are there any projects that could use more developers?  I would imagine
  there are some that are saturated, while some other projects are moving
  slower than the rest.
 
  I'd be willing to work on just about anything, it'll just take me some
  time to get up to speed.  I've programmed in Python for years using
  libraries like SQLAlchemy and Flask, I've just never worked with a
  CI/automated environment before.
 
  Any tips and points in the right direction would be greatly appreciated.
 

 Marconi's team is definitely interested in your contributions, you can
 take a look here[0] and see if you like the project.

 Welcome,
 Flavio

 [0] https://wiki.openstack.org/wiki/Marconi/


 --
 @flaper87
 Flavio Percoco

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] Introducing task oriented workflows

2014-05-23 Thread Endre Karlson
I think Cinder has some of the same sauce ?

https://review.openstack.org/#/c/94742/
https://review.openstack.org/#/c/95037/



2014-05-23 10:57 GMT+02:00 Jaume Devesa devv...@gmail.com:

 ​Hello,

 I think the Mistral Project[1] aims the same goal, isn't it?

 Regards,
 jaume

 [1]: https://wiki.openstack.org/wiki/Mistral


 On 23 May 2014 09:28, Salvatore Orlando sorla...@nicira.com wrote:

 Nachi,

 I will be glad if the solution was as easy as sticking a task_state
 attribute to a resource! I'm afraid however that would be only the tip of
 the iceberg, or the icing of the cake, if you want.
 However, I agree with you that consistency across Openstack APIs is very
 important; whether this is a cross project discussion is instead debatable;
 my feeling here is that taskflow is the cross-project piece of the
 architecture, and every project then might have a different strategy for
 integrating it - as long as it does not result in inconsistent APIs exposed
 to customers!

 It is something that obviously will be considered when designing how to
 represent whether a DB resource is in sync with its actual configuration on
 the backend.
 I think this is something which might happen regardless of whether it
 will be also agreed to let API consumers access task execution information
 using the API.

 Salvatore




 On 23 May 2014 01:16, Nachi Ueno na...@ntti3.com wrote:

 Hi Salvatore

 Thank you for your posting this.

 IMO, this topic shouldn't be limited for Neutron only.
 Users wants consistent API between OpenStack project, right?

 In Nova, a server has task_state, so Neutron should do same way.



 2014-05-22 15:34 GMT-07:00 Salvatore Orlando sorla...@nicira.com:
  As most of you probably know already, this is one of the topics
 discussed
  during the Juno summit [1].
  I would like to kick off the discussion in order to move towards a
 concrete
  design.
 
  Preamble: Considering the meat that's already on the plate for Juno,
 I'm not
  advocating that whatever comes out of this discussion should be put on
 the
  Juno roadmap. However, preparation (or yak shaving) activities that
 should
  be identified as pre-requisite might happen during the Juno time frame
  assuming that they won't interfere with other critical or high priority
  activities.
  This is also a very long post; the TL;DR summary is that I would like
 to
  explore task-oriented communication with the backend and how it should
 be
  reflected in the API - gauging how the community feels about this, and
  collecting feedback regarding design, constructs, and related
  tools/techniques/technologies.
 
  At the summit a broad range of items were discussed during the
 session, and
  most of them have been reported in the etherpad [1].
 
  First, I think it would be good to clarify whether we're advocating a
  task-based API, a workflow-oriented operation processing, or both.
 
  -- About a task-based API
 
  In a task-based API, most PUT/POST API operations would return tasks
 rather
  than neutron resources, and users of the API will interact directly
 with
  tasks.
  I put an example in [2] to avoid cluttering this post with too much
 text.
  As the API operation simply launches a task - the database state won't
 be
  updated until the task is completed.
 
  Needless to say, this would be a radical change to Neutron's API; it
 should
  be carefully evaluated and not considered for the v2 API.
  Even if it is easily recognisable that this approach has a few
 benefits, I
  don't think this will improve usability of the API at all. Indeed this
 will
  limit the ability of operating on a resource will a task is in
 execution on
  it, and will also require neutron API users to change the paradigm the
 use
  to interact with the API; for not mentioning the fact that it would
 look
  weird if neutron is the only API endpoint in Openstack operating in
 this
  way.
  For the Neutron API, I think that its operations should still be
  manipulating the database state, and possibly return immediately after
 that
  (*) - a task, or to better say a workflow will then be started,
 executed
  asynchronously, and update the resource status on completion.
 
  -- On workflow-oriented operations
 
  The benefits of it when it comes to easily controlling operations and
  ensuring consistency in case of failures are obvious. For what is
 worth, I
  have been experimenting introducing this kind of capability in the NSX
  plugin in the past few months. I've been using celery as a task queue,
 and
  writing the task management code from scratch - only to realize that
 the
  same features I was implementing are already supported by taskflow.
 
  I think that all parts of Neutron API can greatly benefit from
 introducing a
  flow-based approach.
  Some examples:
  - pre/post commit operations in the ML2 plugin can be orchestrated a
 lot
  better as a workflow, articulating operations on the various drivers
 in a
  graph
  - operation spanning multiple plugins (eg: 

Re: [openstack-dev] Point of Contact Request for MagnetoDB

2014-05-09 Thread Endre Karlson
Is NASA still using OpenStack or ?


2014-05-09 19:10 GMT+02:00 Mathews, Tiffany J. (LARC-E301)[SCIENCE SYSTEMS
AND APPLICATIONS, INC] tiffany.j.math...@nasa.gov:

  I am interested in establishing an expert POC for questions and concerns
 regarding MagnetoDB as I am working on creating a technology repository
 for one of the NASA Data Centers to identify and track technologies that we
 may not be currently using, however, would like to consider for potential
 future use. MagnetoDB is a technology that we are interested in learning
 about more- especially with regard to security. We are also interested in
 seeing if there are any white papers or demonstrations that could help us
 better understand this technology.

  Any guidance is greatly appreciated!

  Tiffany Mathews





 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] Re-using Horizon bits in OpenDaylight

2014-01-10 Thread Endre Karlson
Hello everyone.

I would like to know if anyone here has knowledge on how easy it is to use
Horizon for something else then OpenStack things?

I'm the starter of the dlux project that aims to consume the OpenDaylight
SDN controller Northbound REST APIs instead of the integrated UI it has
now. Though the current PoC is done using AngularJS i came into issues like
how we make it easy for third part things that are not core to plugin it's
things into the app which I know that can be done using panels and alike in
Horizon.

So the question boils down to, can I easily re-use Horizon for ODL?

Endre
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Horizon] Abdicating the PTL Position

2013-10-31 Thread Endre Karlson
Hey, I'm just curious. You quitting the PTL position to focus on Nebula
efforts or ?


2013/10/31 Gabriel Hurley gabriel.hur...@nebula.com

 Hi all,

 It saddens me to say that for a mix of reasons I have decided to abdicate
 my position as PTL for Horizon. If anything, the reasons are all good ones
 overall, I just have to make the right decision for both myself and the
 project.

 In the interim David Lyle will be the acting PTL. The Horizon core team
 has all weighed in with their confidence in his abilities, and he has
 confirmed his ability and interest in doing so. There will be a nomination
 period in coming weeks to determine the PTL for the full release cycle,
 should anyone else wish to run for the job as well. Thierry will announce
 more information about that soon.

 Rest assured, you're not rid of me entirely; I'm just making a decision to
 focus in on other areas for a time. Horizon is blessed to have other
 phenomenal candidates willing and able to lead, and I would rather see the
 project in the hands of someone who can devote their full attention and
 energy to it.

 I will still be around and engaged (though not in Hong Kong). I'll catch
 you all next time around.

 All the best,

 - Gabriel Hurley

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Horizon] Abdicating the PTL Position

2013-10-31 Thread Endre Karlson
Nevermind and ignore the last e-mail, it was wrongly intended.

Endre


2013/10/31 Endre Karlson endre.karl...@gmail.com

 Hey, I'm just curious. You quitting the PTL position to focus on Nebula
 efforts or ?


 2013/10/31 Gabriel Hurley gabriel.hur...@nebula.com

 Hi all,

 It saddens me to say that for a mix of reasons I have decided to abdicate
 my position as PTL for Horizon. If anything, the reasons are all good ones
 overall, I just have to make the right decision for both myself and the
 project.

 In the interim David Lyle will be the acting PTL. The Horizon core team
 has all weighed in with their confidence in his abilities, and he has
 confirmed his ability and interest in doing so. There will be a nomination
 period in coming weeks to determine the PTL for the full release cycle,
 should anyone else wish to run for the job as well. Thierry will announce
 more information about that soon.

 Rest assured, you're not rid of me entirely; I'm just making a decision
 to focus in on other areas for a time. Horizon is blessed to have other
 phenomenal candidates willing and able to lead, and I would rather see the
 project in the hands of someone who can devote their full attention and
 energy to it.

 I will still be around and engaged (though not in Hong Kong). I'll catch
 you all next time around.

 All the best,

 - Gabriel Hurley

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Horizon] Abdicating the PTL Position

2013-10-31 Thread Endre Karlson
@Gabriel, thanks for an awesome time leading Horizon in towards what is now
a awesome Framework / UI for OpenStack! I'm sure you'll bring awesome to
whatever you're doing next!

It's very sad to see good people leave the PTL positions but hey, time goes
by and people do new things.

Good luck and see you around dude, it was awesome to meet you in Portland
in the last summit :)

Endre.


2013/10/31 Endre Karlson endre.karl...@gmail.com

 Nevermind and ignore the last e-mail, it was wrongly intended.

 Endre


 2013/10/31 Endre Karlson endre.karl...@gmail.com

 Hey, I'm just curious. You quitting the PTL position to focus on Nebula
 efforts or ?


 2013/10/31 Gabriel Hurley gabriel.hur...@nebula.com

 Hi all,

 It saddens me to say that for a mix of reasons I have decided to
 abdicate my position as PTL for Horizon. If anything, the reasons are all
 good ones overall, I just have to make the right decision for both myself
 and the project.

 In the interim David Lyle will be the acting PTL. The Horizon core team
 has all weighed in with their confidence in his abilities, and he has
 confirmed his ability and interest in doing so. There will be a nomination
 period in coming weeks to determine the PTL for the full release cycle,
 should anyone else wish to run for the job as well. Thierry will announce
 more information about that soon.

 Rest assured, you're not rid of me entirely; I'm just making a decision
 to focus in on other areas for a time. Horizon is blessed to have other
 phenomenal candidates willing and able to lead, and I would rather see the
 project in the hands of someone who can devote their full attention and
 energy to it.

 I will still be around and engaged (though not in Hong Kong). I'll catch
 you all next time around.

 All the best,

 - Gabriel Hurley

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [oslo] new libraries

2013-10-29 Thread Endre Karlson
oslo.logging
oslo.db

Is there any ideas on introducing these libraries post-summit time?

Endre
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] Consolidation for Manager and Resource classes

2013-10-16 Thread Endre Karlson
Has anyone looked into doing a effort in consolidating the different
implementations of these classes ?

Doing a short walk-through I see:

Manager
  * Has a typical kind of API (server, lb, network, subnet) which it
interacts with and returns instances of a result as a Resource
Resource
  * Represents a instance of a object.

# Nova
https://github.com/openstack/python-novaclient/

https://github.com/openstack/python-novaclient/blob/master/novaclient/base.py

# Neutron
https://github.com/openstack/python-neutronclient
N/A?

# Glance
https://github.com/openstack/python-glanceclient

https://github.com/openstack/python-glanceclient/blob/master/glanceclient/common/base.py

# Keystone
https://github.com/openstack/python-keystoneclient/

https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/base.py

# Cinder
https://github.com/openstack/python-cinderclient/

https://github.com/openstack/python-cinderclient/blob/master/cinderclient/base.py

# Ceilometer
https://github.com/openstack/python-ceilometerclient/

https://github.com/openstack/python-ceilometerclient/blob/master/ceilometerclient/common/base.py

# Heat
https://github.com/openstack/python-heatclient

https://github.com/openstack/python-heatclient/blob/master/heatclient/common/base.py

# Ironic
https://github.com/openstack/python-ironicclient

https://github.com/openstack/python-ironicclient/blob/master/ironicclient/common/base.py

# Tuskar
https://github.com/openstack/python-tuskarclient

https://github.com/openstack/python-tuskarclient/blob/master/tuskarclient/common/base.py

# Trove
https://github.com/openstack/python-troveclient

https://github.com/openstack/python-troveclient/blob/master/troveclient/base.py

# Marconi
https://github.com/openstack/python-marconiclient
N/A?

# Savanna
https://github.com/openstack/python-savannaclient

https://github.com/openstack/python-savannaclient/blob/master/savannaclient/api/base.py

# Manila
https://github.com/stackforge/python-manilaclient

https://github.com/stackforge/python-manilaclient/blob/master/manilaclient/base.py


They are all doing the same thing, so why not put them into a common place?

Endre
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Consolidation for Manager and Resource classes

2013-10-16 Thread Endre Karlson
I can see though that there is a apiclient thing in oslo-incubator, would
it be an idea to name this oslo.client instead of having to copy this in
like other oslo stuff?

Endre


2013/10/16 Lucas Alvares Gomes lucasago...@gmail.com

 +1 to consolidate.

 They are all doing the same thing, so why not put them into a common place?


 *almost* the same thing, there's some small differences, one e.g is that
 Ironic use PATH for the update instead of PUT.

 Cheers,
 Lucas

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases

2013-10-09 Thread Endre Karlson
What about also allowing a specific service to request a port to be created
on a requested server for an arbitrary service like a physical machine?

I think we should think more in terms of s/VM/Instance where instance can
really be either a VM or a Physical host since it really doesn't matter..

Endre


2013/10/9 Bob Melander (bmelande) bmela...@cisco.com

  For use case 2, ability to pin an admin/operator owned VM to a
 particular tenant can be useful.
 I.e., the service VMs are owned by the operator but a particular service
 VM will only allow service instances from a single tenant.

  Thanks,
 Bob

   From: Regnier, Greg J greg.j.regn...@intel.com
 Reply-To: OpenStack Development Mailing List 
 openstack-dev@lists.openstack.org
 Date: tisdag 8 oktober 2013 23:48
 To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org
 
 Subject: [openstack-dev] [Neutron] Service VM discussion - Use Cases

   Hi,

 ** **

 Re: blueprint:
 https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms

 Before going into more detail on the mechanics, would like to nail down
 use cases.  

 Based on input and feedback, here is what I see so far.  

 ** **

 Assumptions:

  

 - a 'Service VM' hosts one or more 'Service Instances'

 - each Service Instance has one or more Data Ports that plug into Neutron
 networks

 - each Service Instance has a Service Management i/f for Service
 management (e.g. FW rules)

 - each Service Instance has a VM Management i/f for VM management (e.g.
 health monitor)

  

 Use case 1: Private Service VM 

 Owned by tenant

 VM hosts one or more service instances

 Ports of each service instance only plug into network(s) owned by tenant**
 **

  

 Use case 2: Shared Service VM

 Owned by admin/operator

 VM hosts multiple service instances

 The ports of each service instance plug into one tenants network(s)

 Service instance provides isolation from other service instances within VM
 

  

 Use case 3: Multi-Service VM

 Either Private or Shared Service VM

 Support multiple service types (e.g. FW, LB, …)

 ** **

 -  Greg

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] Keystone + AD / LDAP problem

2013-10-04 Thread Endre Karlson
Hi, I have a problem with my keystone where it doesn't honor the setting
under the [identity] section with the user_id_attribute setting set to
'sAMAccountName'. I have reported a comment on a existing bug:
https://bugs.launchpad.net/keystone/+bug/1210141

Any clues on what I am doing wrong?

I got Windows server 2008 as the AD / LDAP .

Endre
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Neutron] - Evacuate a agent node

2013-09-12 Thread Endre Karlson
Is it possible to get a evacuation command for a node running agents ?
Say moving all the agents owned resources from network node a  b?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] Horizon - Mockup tool

2013-08-29 Thread Endre Karlson
Does anyone know what too is used to do mockups ?

Endre
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] Host evacuation

2013-07-19 Thread Endre Karlson
Would it be an idea to make the host evacuation to use the scheduler to
pick where the VMs are supposed to address the note
http://sebastien-han.fr/blog/2013/07/19/openstack-instance-evacuation-goes-to-host/?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] Rating engine for BillingStack

2013-06-28 Thread Endre Karlson
Hi, I would like to get some input on what kind of rating rules engine we
could use for BS.

Basically there are two alternatives as we see it now:
Drools as a service besides the Python components in BS using
https://github.com/droolsjbpm/drools-wb as a UI and interact with it as a
webservice
Python Intellect

Does anyone else have input on the matter?

Endre
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev