Re: [openstack-dev] [neutron][taas] proposal: dedicated tunnel for carrying mirrored traffic
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
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
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
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
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
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
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] [Neutron] Introducing task oriented workflows
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
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
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
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
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
@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
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
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
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
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
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
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
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
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
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
