Re: [openstack-dev] [Barbican] re: MIME types vs path (secrets/{id}/{name})
Thanks for a very complete answer.
While I agree that it's OK if there is only going to be one secret to use
the Accept type (it is actually a nice idea), it doesn't seem that MIME
types are really suitable if there are multiple secrets per URI.
So I don't think that fixing this should be punted too far into the future,
given that it sounds like you'll have to break the API (and thus all tests,
docs, clients, compatible implementations etc).
Justin
On Sun, Sep 22, 2013 at 10:13 PM, John Wood john.w...@rackspace.com wrote:
Hello Justin,
First off, the current implementation of Barbican only supports one
encrypted payload per secret record. We plan to revisit this once we begin
work on the SSL certificate processing features.
As for the Barbican API, please note that the latest Barbican API is
located here:
https://github.com/cloudkeep/barbican/wiki/Application-Programming-Interface
As detailed in this wiki page, the current implementation of Barbican
utilizes an 'Accept' request header to indicate to the Barbican service
which media type to return the secret in. If 'application/json' is
provided, only the secret's metadata is returned (i.e. nothing is
decrypted). Alternate 'Accept' types may then be used to decrypted and
return the secret, such as 'application/octet-stream' from binary secret
types, and 'text/plain' for text based secrets.
Effectively these are different representations of the same REST-ful
secret resource, which we believe is an acceptable (no pun intended) use
of the 'Accept' header, but open for further debate.
That said, we did encounter an issue related to the 'Accept-Encoding'
request header. We had hoped to use this header to indicate if (for
example) a binary secret should be returned as 'base64' encoded versus raw
binary data. We found the ability to override this header from default was
problematic on Chrome, so decided to hold off on this feature for now.
Curiously one option discussed was to add a '/base64' extension to the URI.
Hence this feature could similarly be open for debate.
BTW, we do have a Python client library available for interaction with
Barbican as well: https://github.com/cloudkeep/python-barbicanclient
Thanks,
John
--
*From:* Justin Santa Barbara [jus...@fathomdb.com]
*Sent:* Sunday, September 22, 2013 2:25 PM
*To:* OpenStack Development Mailing List
*Subject:* [openstack-dev] [Barbican] MIME types vs path
(secrets/{id}/{name})
As part of my project to add a second implementation of the OpenStack
API, I'm implementing Barbican, and I'm struggling to understand the
motivations behind the API spec.
The API supports storing multiple secrets under a given key, the
canonical example for that being SSL keys which comprise a
certificate/public key and a private key. That makes sense.
But, to set or retrieve the sub-secrets, the MIME type of the request
is used. 'application/json' is special and retrieves the metadata.
Wouldn't it be much easier just to use a path ( i.e.
.../secrets/{id}/{name} ), rather than using MIME types? Using MIME types
seems very un-RESTy, but I'll leave that argument to the REST police :-)
It seems much more complicated to use MIME types, so I'm betting there's
a good reason. Can someone from the Barbican team share what those are?
(The API ref I'm looking at is here:
https://github.com/cloudkeep/barbican/wiki/Blueprint%3A-MIME-Type-Revamp )
Justin
---
Justin Santa Barbara
Founder, FathomDB
___
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 PTL election
Hey I meant to send this as soon as nominations opened - I figure that incumbent PTLs should make it clear if they don't intend to nominate themselves for re-election. To that end - I'm not going to put myself forward for election as Oslo PTL this time around. This is purely based on a gut instinct that doing so will actually be better for Oslo. I still care a great deal about Oslo's mission and will continue to work on Oslo in Icehouse, e.g. doing reviews and getting the oslo.messaging work over the line. I think the legacy of cut-and-paste code across OpenStack is a serious threat to OpenStack's future progress and tackling it effectively is going to require the help of many more of the core developers from other projects. I'm hoping that by not being PTL, there'll be more space for others to jump in and help drive Oslo's direction with new ideas and new approaches. Thanks, Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Oslo] PTL Candidacy
On Sat, 2013-09-21 at 09:16 -0400, Doug Hellmann wrote: I am running for PTL for the OpenStack Common Libraries (Oslo) project. Excellent! Doug has been a superb contributor to Oslo and I've particularly appreciated his keen eye for Python API design. I've no doubt that Doug would make a wonderful PTL for Oslo. Thanks, Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Climate] Use Taskflow for leases start/end ?
I can't agree more. My point was not using it for v1, but just make sure everoybody in the team is aware of that kind of transactional framework. On a second pro, it would make sense to conceptualize transaction model and think on a move later, even if we're still yet not using it :-) Taskflow ppl, do you have any kind of code freeze deadline which could give us a glance on when the first release will be ready for use ? Thanks, -Sylvain Le 22/09/2013 09:39, Dina Belova a écrit : Hi all, I think that TaskFlow is an interesting initiative that could provide us some benefits like good encapsulation of logical code blocks, better exception handling and management of actions taking place in Climate core, rollbacks and replays management. It looks like that we should initially understand our workflows in Climate and then decide if we should use TaskFlow for them or not. On Thu, Sep 19, 2013 at 4:54 PM, Sylvain Bauza sylvain.ba...@bull.net mailto:sylvain.ba...@bull.net wrote: Hi Climate team, I just went through https://wiki.openstack.org/wiki/TaskFlow Do you think Taskflow could help us in providing ressources defined in the lease on an atomic way ? We could leave the implementation up to the plugins, but maybe the Lease Manager could also benefit of it. -Sylvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ 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] [cinder]The inconsistency between cinder client v1 and v2 supported arguments.
Hi all, When I was fixing bug 1221611, current codeReview link. I found in CinderClient component, there are many inconsistent arguments in v1 and v2 shell.py. Consider backwards compatibility and consistency, I think we need to fix this problem. For convenience, I made the following list of v1/v2 arguments inconsistency, please review it, the folks who have better understanding of the CLI client history please provide more insights on how to deal with current situation. Thanks! Method V1 V2 do_rename Only support --display-description argument, do not support --display_description Support both (--display-description and --display_description) do_snapshot_list Do not support --display_name and --volume_id argument Support both do_snapshot_rename Do not support --display_description Support --display_description do_upload_image Do not support --container_format --disk_format and --image_name Support these arguments Thanks Best Regards Yu Da Zhao(于大钊) -- Cloud Solutions OpenStack Development China Systems Technology Laboratory in Beijing Email: d...@cn.ibm.com Tel: (86)10-82450677 -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Client and Policy
On 20/09/13 15:20 -0700, Monty Taylor wrote: On 09/20/2013 02:55 PM, Ben Nemec wrote: Not from a Gerrit perspective, but the Oslo policy is that a maintainer +1 on the code they maintain is the equivalent of a +2, so only one core is needed to approve. See https://github.com/openstack/oslo-incubator/blob/master/MAINTAINERS#L28 What if we rethought the organization just a little bit. Instead of having oslo-incubator from which we copy code, and then oslo.* that we consume as libraries, what if: - we split all oslo modules into their own repos from the start IIRC, we're planning to have a design session around these lines at the summit. I think the only issue here is figuring out where some modules belong. For example, where would we put strutils? Should we have a single repo for it or perhaps have a more generic one, say oslo.text, were we could group strutils, jsonutils and some other modules? There are plenty of single-file packages out there but I'd personally prefer grouping modules as much as possible. Another thing to consider is, what happens with Oslo modules depending on other oslo modules? I guess we would make sure all the dependencies are copied in the project as we do today but, when it comes to testing the single module, I think this could be an issue. For example, policy.py depends on fileutils, gettextutils and other oslo module which wouldn't fit in the same package, oslo.policy. This will make testing oslo.policy a real pain since we would have to copy its dependencies in its own tree as well. - we make update.py a utility that groks copying from a directory that contains a bunch of repos - so that a person wanting to use is might have: ~/src ~/src/oslo ~/src/oslo/oslo.db ~/src/oslo/oslo.policy and then when they run update.py ~/src/oslo ~/src/nova and get the same results (the copying and name changing and whatnot) If we split modules in its own repos, I'd rather use git submodules, which would then work better. That way, we can add per-module additional core easily like we can for released oslo modules (like hacking and pbr have now) +1 Also, that would mean that moving from copying to releasing is more a matter of just making a release than it is of doing the git magic to split the repo out into a separate one and then adding the new repo to gerrit. +1 Thoughts? I like the idea overall, I'm a bit worried about how those modules would be organized. Any thoughts about the above concerns? Cheers, FF -- @flaper87 Flavio Percoco ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] sqlalchemy version regression
On 09/23/2013 06:48 AM, Thomas Goirand wrote: On 09/23/2013 01:36 PM, Thomas Goirand wrote: On 09/23/2013 11:04 AM, Pádraig Brady wrote: OpenStack should be compatible with sqlalchemy 0.8.x at this stage, or should be easily tweaked to be so. My view as well. sqlalchemy-migrate will be a bit awkward though as upstream seems to have moved to alembic and is no longer that interested in maintenance/releases. So what would be the best way to handle that? This has already been discussed in July: http://lists.openstack.org/pipermail/openstack-dev/2013-July/011755.html However, I'm not sure how the plan went through. For distros it's easy, just patch their latest python-migrate-0.7.2 packages with: http://pkgs.fedoraproject.org/cgit/python-migrate.git/plain/python-migrate-sqlalchemy-0.8.patch and maybe this for postgres support too: http://www.mergely.com/editor?lhs=https://raw.github.com/lugensa/sqlalchemy-migrate/1f87b7c4/migrate/changeset/ansisql.pyrhs=https://raw.github.com/lugensa/sqlalchemy-migrate/master/migrate/changeset/ansisql.py Is this the new upstream repository? I have already applied some patches to fix sqlalchemy-migrate wrt sqlalchemy 0.8 in Debian. I believe that was enough to make it work. Thomas Having a deeper look, I have found: https://github.com/stackforge/sqlalchemy-migrate Cool, and both the above patches are already there. The first with: https://github.com/stackforge/sqlalchemy-migrate/commit/2ff11c17 https://github.com/stackforge/sqlalchemy-migrate/commit/74ccf7a3 The second (which I have an untested alternative for) at: https://github.com/stackforge/sqlalchemy-migrate/commit/c670d1d3#commitcomment-4154121 However, there's no new release. Could someone tag and release a new version I suppose we might tag/use a version between 0.7.2 = and = 0.7.3 to allow official upstream to release in future without clashes? Or do we use 0.8... to indicate sqlalchemy 0.8 compat? Oh I see we've pypi creds for this too: http://lists.openstack.org/pipermail/openstack-dev/2013-July/011767.html So we can control versions from now on? so that it can be packaged in Debian? I'd update Fedora/EPEL to use that release if available too. thanks! Pádraig. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][libvirt] Should file injection work for boot from volume images?
On 09/21/2013 12:02 AM, Pádraig Brady wrote: On 09/20/2013 10:47 PM, Michael Still wrote: Before https://review.openstack.org/#/c/46867/ if file injection of a mandatory file fails, nova just silently ignores the failure, which is clearly wrong. For reference, the original code you're adjusting is https://review.openstack.org/#/c/18900 BTW, I'm not sure of your adjustments but that's beside the point and best left for discussion at the above review. However, that review now can't land because its revealed another failure in the file injection code via tempest, which is... Should file injection work for instances which are boot from volume? For consistency probably yes. Now that we actually notice injection failures we're now failing to boot such instances as file injection for them doesn't work. I'm undecided though -- should file injection work for boot from volume at all? Or should we just skip file injection for instances like this? I'd prefer to see us just support config drive and metadata server for these instances, but perhaps I am missing something really important. Now I wouldn't put too much effort into new file injection mechanisms, but in this case it might be easy enough to support injection to volumes. In fact there was already an attempt made at: https://review.openstack.org/#/c/33221/ I agree with Monty and Thierry that ideally file injection should DIAF everywhere. On that note, have we done anything with that in the v3 API? I propose we remove it completely. However, I also agree with Pádraig here that for the sake of consistency, as long as file injection is supported, I would expect this to work. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Questions about plans for heat wadls moving forward
Hi Anne Steve, I already have removing the original heal WADL in my work plan. I am just waiting for the released version of the clouddocs maven plugin to be fixed (1.10.0) to support pulling the wadl content into the api-ref doc (https://github.com/openstack/heat/blob/master/doc/docbkx/api-ref/src/docbkx/api-ref.xml) from the orchestration wadl in the api-ref site. Mike From: Steven Dake sd...@redhat.commailto:sd...@redhat.com Reply-To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Friday, September 20, 2013 2:46 PM To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: Anne Gentle annegen...@justwriteclick.commailto:annegen...@justwriteclick.com Subject: Re: [openstack-dev] [Heat] Questions about plans for heat wadls moving forward On 09/13/2013 01:21 PM, Anne Gentle wrote: On Fri, Sep 13, 2013 at 1:53 PM, Mike Asthalter mike.asthal...@rackspace.commailto:mike.asthal...@rackspace.com wrote: Hi Anne, I want to make sure I've understood the ramifications of your statement about content sharing. So for now, until the infrastructure team provides us with a method to share content between repos, the only way to share the content from the orchestration wadl with the api-ref doc (https://github.com/openstack/heat/blob/master/doc/docbkx/api-ref/src/docbkx/api-ref.xml) is to manually copy the content from the orchestration wadl to the original heat wadl and then use that for the shared content. So we will not delete the original heat wadl until that new method of content sharing is in place. Is this correct? Hi Mike, It sounds like the dev team is fine with deleting that original heat WADL and only maintaining one from here forward. The way they will control Icehouse edits to the heat WADL that shouldn't yet be displayed to end users is to use the Work In Progress button on review.openstack.orghttp://review.openstack.org. When a patch is marked WIP, you can't merge it. So, you can safely delete the original Heat WADL and then from your dev guides, if you want to include a WADL, you can point to the one in the api-site repository. We now have a mirror of the github.comhttp://github.com repository at git.openstack.orghttp://git.openstack.org that gives you access to the WADL in the api-site repository at all times. I can walk you through building the URL that points to the WADL file. Anne, Sorry for delay in response - I've been traveling. I will submit a change to remove the wadl from the heat repo since the api-site is finished. Regards -steve What we also need to build is logic in the build jobs so that any time the api-site WADL is updated, your dev guide is also updated. This is done in the Jenkins job in https://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/jenkins_job_builder/config/api-jobs.yaml. I can either submit this patch for you, or I'll ask Steve or Zane to do so. Hope this helps - Anne Thanks! Mike From: Anne Gentle annegen...@justwriteclick.commailto:annegen...@justwriteclick.com Reply-To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, September 12, 2013 11:32 PM To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Heat] Questions about plans for heat wadls moving forward On Thu, Sep 12, 2013 at 10:41 PM, Monty Taylor mord...@inaugust.commailto:mord...@inaugust.com wrote: On 09/12/2013 04:33 PM, Steve Baker wrote: On 09/13/2013 08:28 AM, Mike Asthalter wrote: Hello, Can someone please explain the plans for our 2 wadls moving forward: * wadl in original heat repo: https://github.com/openstack/heat/blob/master/doc/docbkx/api-ref/src/wadls/heat-api/src/heat-api-1.0.wadl %22https://github.com/openstack/heat/blob/master/doc/docbkx/api-ref/src/wadls/heat-api/src/heat-api-1. * wadl in api-site repo: https://github.com/openstack/api-site/blob/master/api-ref/src/wadls/orchestration-api/src/v1/orchestration-api.wadl The original intention was to delete the heat wadl when the api-site one became merged. Sounds good. 1. Is there a need to maintain 2 wadls moving forward, with the wadl in the original heat repo containing calls that may not be implemented, and the wadl in the api-site repo containing implemented calls only? Anne Gentle advises as follows in regard to these 2 wadls: I'd like the WADL in api-site repo to be user-facing. The other WADL can be truth if it needs to be a specification that's not yet implemented. If the WADL in api-site repo is true and implemented, please just maintain one going forward. 2. If we maintain 2 wadls, what are the consequences (gerrit reviews, docs out of sync, etc.)? 3. If we maintain only the 1
Re: [openstack-dev] [Horizon] Ceilometer Alarm management page
On Thu, Sep 19 2013, Ladislav Smola wrote: Hi Ladislav, Sorry for the late reply, 1. The points 1-4 from are some sort simple version of the page, that uses all basic alarm-api features. Do you think we need them all? Any feedback for them? Enhancements? That looks like a really good start if we can have all of this! 2. There is a thought, that we should maybe divide Alarms into (System, User-defined). The only system alarms now, are set up with Heat and used for auto-scaling. I don't think there is any formal way to distinguish alarms. Though it's likely you can retrieve the alarm list Heat created for the user to distinguish them. On the other hand, I am not sure the user can see the alarms created by Heat since they might not directly belong to the user, but to Heat. 3. There is a thought about watching correlation of multiple alarm histories in one Chart (either Alarm Histories, or the real statistics the Alarm is defined by). Do you think it will be needed? Any real life examples you have in mind? I think the first use case is to debug combined alarms. There's also a lot of potential to debug an entire platform activity by superimposing several alarm graphs. 4. There is a thought about tagging the alarms by user defined tag, so user can easily group alarms together and then watch them together based on their tag. The alarm API don't provide that directly, but you can imagine some sort of filter based on description matching some texts. 5. There is a thought about generating a default alarms, that could observe the most important things (verifying good behaviour, showing bad behaviour). Does anybody have an idea which alarms could be the most important and usable for everybody? I'm not sure you want to create alarm by default; alarm are resources, I don't think we should create resources without the user asking for it. Maybe you were talking about generating alarm template? You could start with things like CPU usage staying at 90% for more than 1 hour, and having an action that alerts the user via mail. Same for disk usage. 6. There is a thought about making overview pages customizable by the users, so they can really observe, what they need. (includes Ceilometer statistics and alarms) I think that could be as easy as picking the alarms you want in overviews with a very small and narrowed graph. -- Julien Danjou /* Free Software hacker * independent consultant http://julien.danjou.info */ signature.asc Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ceilometer][IceHouse] Ceilometer + Kibana + ElasticSearch Integration
Nachi ... love it! It would be very cool to see how this would work with Events, since they have much more metadata associated with them. This is the sort of stuff I think we should be doing a lot more of. There are so many excellent open source monitoring components out there. Better integration with them should be our focus. Let people assemble the monitoring stack they want. Recently Logstash also joined Kibana, so that's going to make it even better. -S --- Sorry for the new thread. Got dropped from openstack-dev and only found this from the archive. From http://lists.openstack.org/pipermail/openstack-dev/2013-September/015042.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] unable to run tox due to the '--pre' argument
On 09/23/2013 12:14 AM, Zhongyue Luo wrote: Looks like this problem happens in systems that use pip1.4 but upgraded tox to 1.6.1 http://tox.readthedocs.org/en/latest/config.html#confval-install_command=ARGV Yes. We have been rolling out tox.ini changes to projects. I'll push one up for neutronclient right now... https://review.openstack.org/47848 This change should essentially be ported in to all projects. I'm getting to it slowly, but if other people want to step up and do that too, I'd welcome the help! On Fri, Sep 20, 2013 at 12:47 AM, Jeremy Stanley fu...@yuggoth.org mailto:fu...@yuggoth.org wrote: On 2013-09-19 09:24:08 +0800 (+0800), Yongsheng Gong wrote: [...] I upgrade the pip into 1.4.1: gongysh@gongysh-ThinkPad-T530:/opt/stack/python-neutronclient$ .tox/py27/bin/pip install -U pip gongysh@gongysh-ThinkPad-T530:/opt/stack/python-neutronclient$ .tox/py27/bin/pip --version pip 1.4.1 from /mnt/data/opt/stack/python-neutronclient/.tox/py27 /lib/python2.7/site-packages (python 2.7) [...] Then I run tox -e py27 and it failed: [...] I check the pip version in .tox: gongysh@gongysh-ThinkPad-T530:/mnt/data/opt/stack/ python-neutronclient$ .tox/py27/bin/pip --version pip 1.3.1 from /mnt/data/opt/stack/python-neutronclient/.tox/py27 /lib/python2.7/site-packages/pip-1.3.1-py2.7.egg (python 2.7) It is changed back!!! I've tried to reproduce this and it doesn't seem to happen for me. Using tox 1.6.1 to run 'tox -e py27' in a current checkout of python-neutronclient's master branch automatically installs pip 1.4.1 in the virtualenv it creates. Can you try this on another machine/vm just for confirmation? Clark also suggested on IRC just now that maybe you have some global tox configuration specifying to always recreate the virtualenv (essentially -r) and that its populating it with your system-installed version or perhaps an older cached download. -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Intel SSG/STOD/DCST/CIT* 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, China +862161166500 ___ 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] [Tuskar] [UI] Identifying metrics to show in Tuskar UI detail pages
Ladislav All, I've spent some time the last few days trying to identify the metrics that a user would want to view around the details pages for Resource Classes, Racks, and Nodes. The notes have been captured here, where I've also tried to call out the items that are available in Ceilometer currently: https://etherpad.openstack.org/tuskar-metrics A lot of these metrics seem as though they will need to be calculated as aggregates of metrics that are currently available, but some are completely new, I think. Please take a look as you have time and feel free to comment and add things to this etherpad if you identify any metrics that should be shown in these views. I hope to have some basic wireframes based on these metrics to review with the UX community and UI team by the end of the week. Thanks, Liz ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Murano] Meeting Minutes 2013-09-23
Hello, Below, you can see the meeting minutes from today's Murano meeting. Minutes: http://eavesdrop.openstack.org/meetings/murano/2013/murano.2013-09-23-15.04.html Minutes (text): http://eavesdrop.openstack.org/meetings/murano/2013/murano.2013-09-23-15.04.txt Log: http://eavesdrop.openstack.org/meetings/murano/2013/murano.2013-09-23-15.04.log.html The next meeting will be held at 30th Sep. -- Timur, QA Lead OpenStack Murano Project Mirantis Inc ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Tuskar] [UI] Identifying metrics to show in Tuskar UI detail pages
Liz, thank you very much for this, I will try to sort this and pick the ones, that will need to be implemented in Ceilometer. Will comment the etherpad. FYI there are only two Agents, that collects Hardware related data now. This one is almost complete: https://blueprints.launchpad.net/ceilometer/+spec/monitoring-physical-devices This one has just started: https://blueprints.launchpad.net/ceilometer/+spec/ipmi-inspector-for-monitoring-physical-devices Thank you, Ladislav On 09/23/2013 04:55 PM, Liz Blanchard wrote: Ladislav All, I've spent some time the last few days trying to identify the metrics that a user would want to view around the details pages for Resource Classes, Racks, and Nodes. The notes have been captured here, where I've also tried to call out the items that are available in Ceilometer currently: https://etherpad.openstack.org/tuskar-metrics A lot of these metrics seem as though they will need to be calculated as aggregates of metrics that are currently available, but some are completely new, I think. Please take a look as you have time and feel free to comment and add things to this etherpad if you identify any metrics that should be shown in these views. I hope to have some basic wireframes based on these metrics to review with the UX community and UI team by the end of the week. Thanks, Liz ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Is python setup.py intsall recommended way to install Neutron Server in dev environment?
Hi, I am new to openstack, please pardon if the questions are dumb. Attempting to run a neutron dev setup with openvswitch plugin with VLAN isolation and 2 hosts. DISCLAIMER: I am not using devstack. Attempting to install the services in a controller node - Ubuntu12.04 VM. 1. In the controller node a) Services horizon/keystone/glance are installed using apt-get. Yet to install nova. b) Also in addition, for development needs, we have cloned neutron from github c) ran python setup.py install # Is this the recommended way? This seems to have installed all agents /usr/local/bin/neutron-*-agents as well in Controller Node. Thanks, Vijay V. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] cross-stack references
On 18/09/13 19:34, Mike Spreitzer wrote:
When we get into things like affinity concerns or managing network
bandwidth, we see the need for cross-stack relationships. You may want
to place parts of a new stack near parts of an existing one, for
example. I see that in CFN you can make cross-references between
different parts of a single stack using the resource names that appear
in the original template. Is there a way to refer to something that did
not come from the same original template? If not, won't we need such a
thing to be introduced? Any thoughts on how that would be done?
Yes, you can do this now. In fact, nothing in a template should be
making cross-references using only the resource name. Instead you should
use {Ref: resource_name}. The value returned by this varies, but in
most cases it is just the UUID of the resource. You can return this
value in an output, and you can use an input of the same form (i.e. a
UUID in most cases) in place of a Ref to a local resource in cases where
you want to refer to an existing resource instead of one managed by the
template. A similar story applied to attributes (which are just strings)
and Fn::GetAtt.
There's no magic in a template, it's just functions that manipulate strings.
cheers,
Zane.
Fine Print:
We violate this rule in a number of places in Heat, mostly where there's
no real underlying OpenStack API for a given resource type so we've had
to implement the resource within Heat. CloudFormation does not make this
mistake, and I hope to clean up as many of these as possible over time.
However, none of these are likely relevant to the use case you have in mind.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] [scheduler] Bringing things together for Icehouse
On 15/09/13 09:19, Mike Spreitzer wrote: But first I must admit that I am still a newbie to OpenStack, and still am missing some important clues. One thing that mystifies me is this: I see essentially the same thing, which I have generally taken to calling holistic scheduling, discussed in two mostly separate contexts: (1) the (nova) scheduler context, and (2) the ambitions for heat. What am I missing? I think what you're missing is that the only person discussing this in the context of Heat is you. Beyond exposing the scheduling parameters in other APIs to the user, there's nothing here for Heat to do. So if you take [heat] out of the subject line then it will be discussed in only one context, and you will be mystified no longer. Hope that helps :) cheers, Zane. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder]The inconsistency between cinder client v1 and v2 supported arguments.
On Mon, Sep 23, 2013 at 12:18 AM, Da Zhao Y Yu d...@cn.ibm.com wrote: Hi all, When I was fixing bug 1221611, current codeReview link. I found in CinderClient component, there are many inconsistent arguments in v1 and v2 shell.py. Consider backwards compatibility and consistency, I think we need to fix this problem. For convenience, I made the following list of v1/v2 arguments inconsistency, please review it, the folks who have better understanding of the CLI client history please provide more insights on how to deal with current situation. Thanks! We're moving towards dashes in the optional argument name with v2. In v1, optional args that don't support underscores can be changed to do so, but they should still support what they originally supported for compatibility. -Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] [scheduler] Bringing things together for Icehouse
I think this picture is relevant to Heat context: https://docs.google.com/drawings/d/1Y_yyIpql5_cdC8116XrBHzn6GfP_g0NHTTG_W4o 0R9U/edit As more and more types of compute (containers, VMs, bare metal) and other resources (geographically dispersed) become available from the cloud with boarder capabilities (e.g. regionally dispersed backups, failover/recovery, etc.), the concept of scheduling and optimizing resource placement becomes more important, particularly when a customer wants to deploy an application that has multiple underlying resource needs but doesn't want to know (or care) about specifying the details of those resources and their placement. I'm not advocating that this does or does not belongs in Heat (in general I think Stack resource placement, region, etc., belongs with the template author or authoring system, and I think physical resource placement belongs with the underlying service, Nova, Trove, etc.), but I appreciate Mike including Heat on this. I for one would vote that we consider this in-context for discussion purposes, regardless of action. Placement coordination across disparate resource services is likely to become a more prominent problem, and given Heat has the most holistic view of the application topology stack within the cloud, Heat may have something to offer in being a piece of the solution. Kind regards, -Keith On 9/23/13 11:22 AM, Zane Bitter zbit...@redhat.com wrote: On 15/09/13 09:19, Mike Spreitzer wrote: But first I must admit that I am still a newbie to OpenStack, and still am missing some important clues. One thing that mystifies me is this: I see essentially the same thing, which I have generally taken to calling holistic scheduling, discussed in two mostly separate contexts: (1) the (nova) scheduler context, and (2) the ambitions for heat. What am I missing? I think what you're missing is that the only person discussing this in the context of Heat is you. Beyond exposing the scheduling parameters in other APIs to the user, there's nothing here for Heat to do. So if you take [heat] out of the subject line then it will be discussed in only one context, and you will be mystified no longer. Hope that helps :) cheers, Zane. ___ 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] [tuskar] pecan models vs. db models
Hi, during my work on getting tests to pass for https://review.openstack.org/#/c/46947/ I discovered that we are misusing pecan models for HTTP representation of Resources. In controllers pecan/wsme calls actions with pecan model prepopulated from HTTP request's params. For example, when creating new Rack, post method in Racks controller is called with rack object ( https://github.com/stackforge/tuskar/blob/master/tuskar/api/controllers/v1/rack.py#L26-L31 ). This object is instance of Rack from https://github.com/stackforge/tuskar/blob/master/tuskar/api/controllers/v1/types/rack.py . Next this object is used in pecan.request.dbapi.create_rack(rack) call (method defined here https://github.com/stackforge/tuskar/blob/master/tuskar/db/sqlalchemy/api.py#L385-L431 ) This method just assumes that new_rack object (passed from controller) has some attributes with getters defined (name, subnet, location, ...). This is fine if we have 1-1 relationship between how resource is stored in db and how it is represented via HTTP. In fact this assumes that both versions have the same set of atributes. Marios wrote a patch (mentioned above) which needs some internal attributes only, ie. present in table but not exposed via HTTP. In that moment I found that we use pecan models ( https://github.com/stackforge/tuskar/tree/master/tuskar/api/controllers/v1/types ) to transfer HTTP params _directly_ to our db layer ( https://github.com/stackforge/tuskar/blob/master/tuskar/db/sqlalchemy/api.py ). By _directly_ I mean that we assume 1-1 mapping between attributes in pecan models and db models. This is not to be true anymore. We can solve it by using conditionals like this https://review.openstack.org/#/c/46947/3/tuskar/db/sqlalchemy/api.py (lines 175 to 181) but I think this is not good solution b/c of repetion of code and generaly we are mixing up HTTP repr. with db repr. I propose to write a simple layer responsible for translating pecan models into db representation. This way we can keep all diffs in what attributes are exposed via HTTP and which not in one place - easy to see, easy to change, easy to review. To scatter it around dbapi code is not a good way IMHO. Another issue which comes with this coupling of pecan/db models is in tests. In db tests we use utility helpers for creating resources in memory, ie create_test_resource_class method ( https://github.com/stackforge/tuskar/blob/master/tuskar/tests/db/test_db_racks.py#L28 ). This kind of methods comes from from tuskar.tests.db import utils and they use pecan models ( https://github.com/stackforge/tuskar/blob/master/tuskar/tests/db/utils.py#L17-L23 ). We are now on the same page as mentioned above. These db tests uses Relation and Link pecan models which means that easy solution like importing db models instead of pecan models is not doable at the moment b/c db models do not contains direct counterparts for Relation and Link. I am pretty woried about this pecan-db models coupling b/c if (or when) we will need more different stuctures on HTTP side than on db side (no 1-1 relationship) we will have to change our code and tests more. I hope that we will find a solution for this sooner than tuskar code will grow more complex. I would like to see something like service objects in controller part but simple set of translations can be ok if we do not break 1-1 parity too much. Tests will require more attention b/c of that Relation and Link pecan objects. Thank you for your patience with reading this and looking for a feedback. Maybe I missed something or I see this bigger than it really is or I am totally out :-) -- Petr Blaho, pbl...@redhat.com Software Engineer ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Climate] Use Taskflow for leases start/end ?
Howdy there! Taskflow currently should be ready for usage, its not a pypi library yet, I am hoping for a 0.1 release soon (maybe 2 weeksish). But in the meantime it does have a similar `update.py` as oslo-incubator, so you can use that to start integrating. Jump in #openstack-state-management if u have any questions, here to help! -Josh From: Sylvain Bauza sylvain.ba...@bull.netmailto:sylvain.ba...@bull.net Reply-To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Monday, September 23, 2013 12:20 AM To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Climate] Use Taskflow for leases start/end ? I can't agree more. My point was not using it for v1, but just make sure everoybody in the team is aware of that kind of transactional framework. On a second pro, it would make sense to conceptualize transaction model and think on a move later, even if we're still yet not using it :-) Taskflow ppl, do you have any kind of code freeze deadline which could give us a glance on when the first release will be ready for use ? Thanks, -Sylvain Le 22/09/2013 09:39, Dina Belova a écrit : Hi all, I think that TaskFlow is an interesting initiative that could provide us some benefits like good encapsulation of logical code blocks, better exception handling and management of actions taking place in Climate core, rollbacks and replays management. It looks like that we should initially understand our workflows in Climate and then decide if we should use TaskFlow for them or not. On Thu, Sep 19, 2013 at 4:54 PM, Sylvain Bauza sylvain.ba...@bull.netmailto:sylvain.ba...@bull.net wrote: Hi Climate team, I just went through https://wiki.openstack.org/wiki/TaskFlow Do you think Taskflow could help us in providing ressources defined in the lease on an atomic way ? We could leave the implementation up to the plugins, but maybe the Lease Manager could also benefit of it. -Sylvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.orghttp://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] [scheduler] Smart Resource Placement Vision - high level overview document
Hi, We have written a high-level vision document for Smart Resource Placement in Openstack. This covers all the required solutions, and how it relates to some of the proposed blueprints. So this is an attempt to bring the bits together, so that we can collaborate and work towards bringing all of this together. Please review: https://docs.google.com/document/d/1IiPI0sfaWb1bdYiMWzAAx0HYR6UqzOan_Utgml5W1HI/edit?usp=sharing Provides additional details for our proposal of a unified constraints-based resource placement engine. Thanks, Yathi. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] keystone Identity API v3 OS-OAUTH1 Extension
Hello, I would like to try/test the latest Keystone OS-OAUTH1 Extension, but I have not figured out how to access it with the latest H-3 code release. The documentation states that this extension requires v3.0+ of the Identity API. Questions: 1. What version of the Identity API is included in the Havana H-3 release? 2. What URL do I need to use. The following one returns a 404: https://havanatest:35357/v3/OS-OAUTH1/consumers 3. I have added the following lines to keystone.conf. Am I still lacking some configuration items? [oauth1] driver = keystone.contrib.oauth1.backends.sql.OAuth1 [auth] methods = password,token,oauth1 password = keystone.auth.plugins.password.Password token = keystone.auth.plugins.token.Token oauth1 = keystone.auth.plugins.oauth1.OAuth Thanks, Mark ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] keystone Identity API v3 OS-OAUTH1 Extension
Hey Mark, You would also have to add it to the v3 pipeline, by modifying the keystone-paste file. You will also need to create the necessary db tables too. https://github.com/openstack/keystone/blob/master/doc/source/extensions/oauth1-configuration.rst Thanks, _ Steve Martinelli | A4-317 @ IBM Toronto Software Lab Software Developer - OpenStack Phone: (905) 413-2851 E-Mail: steve...@ca.ibm.com From: Miller, Mark M (EB SW Cloud - RD - Corvallis) mark.m.mil...@hp.com To: OpenStack Development Mailing List openstack-dev@lists.openstack.org, Date: 09/23/2013 04:12 PM Subject:[openstack-dev] keystone Identity API v3 OS-OAUTH1 Extension Hello, I would like to try/test the latest Keystone OS-OAUTH1 Extension, but I have not figured out how to access it with the latest H-3 code release. The documentation states that this extension requires v3.0+ of the Identity API. Questions: 1. What version of the Identity API is included in the Havana H-3 release? 2. What URL do I need to use. The following one returns a 404: https://havanatest:35357/v3/OS-OAUTH1/consumers 3. I have added the following lines to keystone.conf. Am I still lacking some configuration items? [oauth1] driver = keystone.contrib.oauth1.backends.sql.OAuth1 [auth] methods = password,token,oauth1 password = keystone.auth.plugins.password.Password token = keystone.auth.plugins.token.Token oauth1 = keystone.auth.plugins.oauth1.OAuth Thanks, Mark ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev inline: graycol.gif___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [heat] Heat PTL election
Hi all, As suggested by markmc earlier[1] it seems sensible for incumbent PTLs to clarify their position if they are not planning to nominate themselves for re-election. Therefore, I'd like to confirm that I do not plan to put myself forward as Heat PTL for the Icehouse cycle. Heat is fortunate in that we have an extremely strong core team, with several members who I'm sure would do a great job serving as PTL. When I stepped into the role, we had discussions about the idea of rotating the PTL responsibility, and since I'm confident that at least one of those folks plans to nominate themselves, I'm happy to step aside and concentrate on coding for Icehouse :) I remain very much committed to the Heat project, I'm looking forward to continuing my work as a core reviewer and contributor. Thanks, Steve [1] http://lists.openstack.org/pipermail/openstack-dev/2013-September/015478.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Heat] PTL candidacy
Hi I would like to announce my candidacy for the Orchestration (Heat) PTL. I have been a software engineer for 16 years and have been developing on Heat for over 12 months. In this period Heat has grown from a small project to being part of the OpenStack ecosystem with a healthy growth in contributors and users. During this time my Heat related development has led to productive relationships with contributors from other projects including Horizon, Infrastructure, Documentation, QA, TripleO and DevStack. The Heat core team has always performed well without the need for prescriptive leadership. Consequently, I feel that this role's primary function is to act as the point of contact with the greater OpenStack community. There is also a need to facilitate the process of reaching consensus, and to advocate for areas which are being neglected. I'm already familiar with most of the tasks of a PTL while filling in for others on several occasions and doing release management for python-heatclient and heat-cfntools. Some of my activity artifacts: https://review.openstack.org/#/q/owner:sbaker%2540redhat.com,n,z https://review.openstack.org/#/q/reviewer:sbaker%2540redhat.com,n,z http://russellbryant.net/openstack-stats/heat-reviewers-180.txt Icehouse During the next cycle, I see these activities as among those the team need to consider: - Growing the core team to match the level of new contributions - Focus on documentation including a comprehensive template writers guide - Resource implementations for all the things, ideally contributed from outside the core developers - Finishing the HOT template format design and implementation - Evaluating the suitability of TaskFlow[1] for Heat - Native autoscaling, with associated autoscaling API. - For projects and cloud providers that adopt Heat, ensuring their needs are being met - Ensuring all Heat features can be used without making any reference to CloudFormation/AWS - Make Heat templates multi-region and multi-cloud aware Finally, despite the overwhelming correlation, and my temporary desire for it to remain so, it is not considered mandatory for the Heat PTL to be called Steve. [1] https://wiki.openstack.org/wiki/TaskFlow ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] keystone Identity API v3 OS-OAUTH1 Extension
Thank you for the pointer. I have it running now. Mark From: Steve Martinelli [mailto:steve...@ca.ibm.com] Sent: Monday, September 23, 2013 1:37 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] keystone Identity API v3 OS-OAUTH1 Extension Hey Mark, You would also have to add it to the v3 pipeline, by modifying the keystone-paste file. You will also need to create the necessary db tables too. https://github.com/openstack/keystone/blob/master/doc/source/extensions/oauth1-configuration.rst Thanks, _ Steve Martinelli | A4-317 @ IBM Toronto Software Lab Software Developer - OpenStack Phone: (905) 413-2851 E-Mail: steve...@ca.ibm.commailto:steve...@ca.ibm.com [Inactive hide details for Miller, Mark M (EB SW Cloud - RD - Corvallis) ---09/23/2013 04:12:15 PM---Hello, I would like to t]Miller, Mark M (EB SW Cloud - RD - Corvallis) ---09/23/2013 04:12:15 PM---Hello, I would like to try/test the latest Keystone OS-OAUTH1 Extension, but I have not figured out From: Miller, Mark M (EB SW Cloud - RD - Corvallis) mark.m.mil...@hp.commailto:mark.m.mil...@hp.com To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org, Date: 09/23/2013 04:12 PM Subject: [openstack-dev] keystone Identity API v3 OS-OAUTH1 Extension Hello, I would like to try/test the latest Keystone OS-OAUTH1 Extension, but I have not figured out how to access it with the latest H-3 code release. The documentation states that this extension requires v3.0+ of the Identity API. Questions: 1. What version of the Identity API is included in the Havana H-3 release? 2. What URL do I need to use. The following one returns a 404: https://havanatest:35357/v3/OS-OAUTH1/consumers 3. I have added the following lines to keystone.conf. Am I still lacking some configuration items? [oauth1] driver = keystone.contrib.oauth1.backends.sql.OAuth1 [auth] methods = password,token,oauth1 password = keystone.auth.plugins.password.Password token = keystone.auth.plugins.token.Token oauth1 = keystone.auth.plugins.oauth1.OAuth Thanks, Mark ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev inline: image001.gif___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon] PTL Candidacy
I hereby declare my candidacy for the Horizon PTL position. My current qualifications: * PTL for the Grizzly and Havana cycles. * Core developer on Horizon since Essex, and Keystone core since Folsom. * Primary architect of the existing Horizon framework. * Core developer for the Django web framework upon which Horizon is built. * Author of the Core Values of Horizon: http://docs.openstack.org/developer/horizon/intro.html * Extensive depth and breadth of knowledge of all of the OpenStack service APIs. * Helped shape the Keystone V3 API and Nova v3 API. * Provided the initial push to internationalize OpenStack as a whole in the Grizzly cycle which has now extended to all projects and dozens of translators. * Ongoing advocate for OpenStack to provide a unified and sensible experience for end users. * Highly engaged in discussions around the future of OpenStack. Things I can't directly take credit for but which happened under my watch (and I'd like to think with my guidance): * Overall contributor base has grown steadily with each release. * Core team expanded significantly in size and diversity. * New OpenStack projects have continued to be represented in each release. * Translation team actively engaged. * UX team formed and steadily becoming an active part of the design and development process. * Essex, Folsom, Grizzly and Havana releases have all been stable, high-quality, on-time, and both forwards and backwards compatible. What I see for Icehouse and beyond: * We have known goals for making Horizon truly event-driven. This is a large job and now is the time. * Downstream distros and large OpenStack providers have given feedback on their pain points; they center around packaging, configuration, and how to alter or remix the OpenStack Dashboard. We can and must improve in these areas. * More projects are entering and graduating from incubation each cycle. We will continue to fulfill our commitment to those projects, and the PTL must engage those projects leaders and their developers to drive their own integrations. * The UX community is giving great insight into how the usability of the dashboard can be improved as it grows. Navigation, user-oriented workflows, and responsive design are low-hanging fruit. * Providing raw data and tools are a base layer, but there are vast green fields for how we can anticipate user questions and needs and provide solutions that cover the 90% cases. * Visualizations and interactivity not only provide better experiences, they also help capture OpenStack mindshare. First impressions matter. * Better integration of help by collaborating with the Docs team connects the end users to the information they need when they need it most. * Multi-region, federation, hybrid public-private, etc. clouds are on the horizon (no pun intended) and we need to start thinking about these issues. All of these lists could go on, but these are the high level items. I want to close by saying that I'm thrilled that someone else in the Horizon community is interested in being PTL, and that the outcome is not a foregone conclusion. It is the highest order of success for a project that there are enough people with passion and vision that there's actually competition for the position. I don't intend to be PTL forever but I believe l have the right experience and vision to guide Horizon through Icehouse. Best of luck to all! - Gabriel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] [scheduler] Bringing things together for Icehouse
Excerpts from Keith Bray's message of 2013-09-23 12:22:16 -0700: I think this picture is relevant to Heat context: https://docs.google.com/drawings/d/1Y_yyIpql5_cdC8116XrBHzn6GfP_g0NHTTG_W4o 0R9U/edit As more and more types of compute (containers, VMs, bare metal) and other resources (geographically dispersed) become available from the cloud with boarder capabilities (e.g. regionally dispersed backups, failover/recovery, etc.), the concept of scheduling and optimizing resource placement becomes more important, particularly when a customer wants to deploy an application that has multiple underlying resource needs but doesn't want to know (or care) about specifying the details of those resources and their placement. I'm not advocating that this does or does not belongs in Heat (in general I think Stack resource placement, region, etc., belongs with the template author or authoring system, and I think physical resource placement belongs with the underlying service, Nova, Trove, etc.), but I appreciate Mike including Heat on this. I for one would vote that we consider this in-context for discussion purposes, regardless of action. Placement coordination across disparate resource services is likely to become a more prominent problem, and given Heat has the most holistic view of the application topology stack within the cloud, Heat may have something to offer in being a piece of the solution. Just to restate what you and Zane have just said succintly: There is definitely a need for Heat to be able to communicate to the API's any placement details that can be communicated. However, Heat should not actually be scheduling anything. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Does quantum work with vmware esxi ?
Hi all, I am thinking about using quantum to do some network setting for the vms on esxi host but I am not sure if it should work or not because the * VMwareVCDriver* is listed as a compute driver. Last time when I enable the quantum service in my devstack installation, there is a boot instance failure when i tried to boot an instance. I dont know the if failure is caused by my devstack setting or it arose just because quantum does not work with esxi. Anyone know if quantum works with esxi ? Thank you xin ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova][vmware] VMwareAPI sub-team reviews update 2013-09-23
Greetings Stackers! We've had a lot of merges lately in the vmwareapi folders so if you have a review pending there, take a moment to git fetch --all and rebase your patch! Thanks for all the attention we've been getting lately, and thanks tot he contributors for staying on top of their respective contributions. Here's a breakdown of the changes I'm tracking. First ordered by priority based on health of the driver, then ordered by the number of +1 votes. We have 6 reviews that look like they're in good shape for a core-reviewer to take a look. Ordered by bug priority: High/Critical https://bugs.launchpad.net/bugs/1223709 https://review.openstack.org/46027 votes:(+2:2,+1:5,-1:0,-2:1), status: needs revision High/Critical https://bugs.launchpad.net/bugs/1226211 https://review.openstack.org/46789 votes:(+2:1,+1:7,-1:0,-2:0), status: needs one more +2/approval High/Critical https://bugs.launchpad.net/bugs/1217541 https://review.openstack.org/43621 votes:(+2:1,+1:2,-1:1,-2:0), status: needs revision High/High https://bugs.launchpad.net/bugs/1226052 https://review.openstack.org/46730 votes:(+2:0,+1:2,-1:0,-2:0), status: needs review High/High https://bugs.launchpad.net/bugs/1171226 https://review.openstack.org/43994 votes:(+2:0,+1:4,-1:0,-2:0), status: ready for core Medium/High https://bugs.launchpad.net/bugs/1207064 https://review.openstack.org/47503 votes:(+2:1,+1:3,-1:1,-2:0), status: needs revision Medium/Medium https://bugs.launchpad.net/bugs/1199954 https://review.openstack.org/46231 votes:(+2:1,+1:3,-1:1,-2:0), status: needs revision High https://bugs.launchpad.net/bugs/1214850 https://review.openstack.org/43270 votes:(+2:0,+1:1,-1:0,-2:0), status: needs review High https://bugs.launchpad.net/bugs/1226826 https://review.openstack.org/47030 votes:(+2:0,+1:5,-1:0,-2:0), status: ready for core High https://bugs.launchpad.net/bugs/1225002 https://review.openstack.org/41977 votes:(+2:0,+1:5,-1:0,-2:0), status: ready for core High https://bugs.launchpad.net/bugs/1227825 https://review.openstack.org/47289 votes:(+2:0,+1:2,-1:0,-2:0), status: needs review High https://bugs.launchpad.net/bugs/1194018 https://review.openstack.org/43641 votes:(+2:1,+1:6,-1:0,-2:0), status: needs one more +2/approval snip trimming anything Medium or below off.. Ordered by fitness for review: == needs one more +2/approval == * https://review.openstack.org/43268 title: 'VMware: enable VNC access without user having to enter pa...' votes: +2:1, +1:3, -1:0, -2:0. +32 days in progress, revision: 13 is 1 days old * https://review.openstack.org/43641 title: 'VMware: Fix ensure_vlan_bridge to work properly with exis...' votes: +2:1, +1:6, -1:0, -2:0. +29 days in progress, revision: 14 is 6 days old * https://review.openstack.org/46789 title: 'VMware: fix bug for incorrect cluster access' votes: +2:1, +1:7, -1:0, -2:0. +7 days in progress, revision: 1 is 7 days old * https://review.openstack.org/46896 title: 'Add linked clone related unit tests for VMware Hyper' votes: +2:1, +1:5, -1:0, -2:0. +6 days in progress, revision: 1 is 6 days old == ready for core == * https://review.openstack.org/43994 title: 'VMwareVCDriver Fix sparse disk copy error on spawn' votes: +2:0, +1:4, -1:0, -2:0. +26 days in progress, revision: 20 is 0 days old * https://review.openstack.org/47030 title: 'VMware: Fix volume detach failure' votes: +2:0, +1:5, -1:0, -2:0. +6 days in progress, revision: 2 is 5 days old * https://review.openstack.org/41977 title: 'VMware: Network fallback in case specified one not found' votes: +2:0, +1:5, -1:0, -2:0. +40 days in progress, revision: 5 is 8 days old == needs review == * https://review.openstack.org/43665 title: 'VMware: Check for the propSet attribute's existence befor...' votes: +2:0, +1:2, -1:0, -2:0. +28 days in progress, revision: 6 is 2 days old * https://review.openstack.org/47289 title: 'fixes datastore selection bug 1227825' votes: +2:0, +1:2, -1:0, -2:0. +5 days in progress, revision: 8 is 0 days old * https://review.openstack.org/46730 title: 'VMware: Fix bug for root disk size' votes: +2:0, +1:2, -1:0, -2:0. +7 days in progress, revision: 10 is 1 days old * https://review.openstack.org/46400 title: 'VMware: booting multiple instances fails if image is not ...' votes: +2:0, +1:2, -1:0, -2:0. +11 days in progress, revision: 7 is 3 days old == needs revision == * https://review.openstack.org/46824 title: 'VMware: Fix SwitchNotFound error when network exists' votes: +2:1, +1:2, -1:1, -2:0. +7 days in progress, revision: 2 is 0 days old *
Re: [openstack-dev] Oslo PTL election
On 09/23/2013 02:37 AM, Mark McLoughlin wrote: Hey I meant to send this as soon as nominations opened - I figure that incumbent PTLs should make it clear if they don't intend to nominate themselves for re-election. To that end - I'm not going to put myself forward for election as Oslo PTL this time around. This is purely based on a gut instinct that doing so will actually be better for Oslo. I still care a great deal about Oslo's mission and will continue to work on Oslo in Icehouse, e.g. doing reviews and getting the oslo.messaging work over the line. I think the legacy of cut-and-paste code across OpenStack is a serious threat to OpenStack's future progress and tackling it effectively is going to require the help of many more of the core developers from other projects. I'm hoping that by not being PTL, there'll be more space for others to jump in and help drive Oslo's direction with new ideas and new approaches. Thanks, Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Knowing your commitment to Open Stack, I don't feel any need to say Sorry to see you go as I know this means just an adjustment of focus for you. What if we said that all core developers on other projects were considered core developers on Oslo? In other words, all of OpenStack has a vested interest in code review of the common components. Would this encourage more reviews in Oslo? Or, would it hurt the overall quality of the Oslo code base? It would certainly broaden the pool of developers, but there would be a need to level set the coding standards. Another approach would be that each of the major projects adopts a subset of Oslo functionality. For example, Keystone could claim responsibility for revewing Crypto and Policy changes. I realize that Oslo already has a way of identifying developers that can review subsets of the code, but this would mean that core projects would collectively have more responsiblity and ownership of the Oslo libraries. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Does quantum work with vmware esxi ?
Compatibility of various Quantum/Neutron plugins with various Nova hypervisors is documented here: http://docs.openstack.org/grizzly/openstack-network/admin/content/flexibility.html . Dan On Mon, Sep 23, 2013 at 4:00 PM, openstack learner openstacklea...@gmail.com wrote: Hi all, I am thinking about using quantum to do some network setting for the vms on esxi host but I am not sure if it should work or not because the * VMwareVCDriver* is listed as a compute driver. Last time when I enable the quantum service in my devstack installation, there is a boot instance failure when i tried to boot an instance. I dont know the if failure is caused by my devstack setting or it arose just because quantum does not work with esxi. Anyone know if quantum works with esxi ? Thank you xin ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- ~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Is python setup.py intsall recommended way to install Neutron Server in dev environment?
On 09/23/2013 01:20 PM, Vijay Venkatachalam wrote: Hi, I am new to openstack, please pardon if the questions are dumb. Attempting to run a neutron dev setup with openvswitch plugin with VLAN isolation and 2 hosts. _DISCLAIMER: _I am not using devstack. Attempting to install the services in a controller node - Ubuntu12.04 VM. 1. In the controller node a) Services horizon/keystone/glance are installed using “apt-get”. Yet to install nova. b) Also in addition, for development needs, we have cloned neutron from github c) ran “python setup.py install” # Is this the recommended way? This seems to have installed all agents “/usr/local/bin/neutron-*-agent”s as well in Controller Node. Yes - this is both fine and expected. I actually recommend a minor variation, for reasons that get very annoying... Instead of: python setup.py install Run: pip install . It should have the exact same result, but pip can succeed in some places where setup.py install directly can fail. Also, if you'd like to run python setup.py develop, simply run: pip install -e . Which will do the same thing. Hrm. I should send that out generally. ___ 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] On the usage of pip vs. setup.py install
tl;dr - easy_install sucks, so use pip It is common practice in python to run: python setup.py install or python setup.py develop So much so that we spend a giant amount of effort to make sure that those always work. Fortunately for us, the underlying mechanism, setuptools, can often be a pile of monkies. pip, while also with its fair share of issues, _is_ a bit better at navigating the shallow waters at times. SO - I'd like to suggest: Instead of: python setup.py install Run: pip install . It should have the exact same result, but pip can succeed in some places where setup.py install directly can fail. Also, if you'd like to run python setup.py develop, simply run: pip install -e . Which you may not have known will run setup.py develop behind the scenes. Things this will help with: - world peace - requirements processing - global hunger - the plague Enjoy. Monty PS. The other should work. It's just sometimes it doesn't, and when it doesn't it's less my fault. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] On the usage of pip vs. setup.py install
On Mon, Sep 23, 2013 at 8:44 PM, Monty Taylor mord...@inaugust.com wrote: tl;dr - easy_install sucks, so use pip It is common practice in python to run: python setup.py install or python setup.py develop So much so that we spend a giant amount of effort to make sure that those always work. Fortunately for us, the underlying mechanism, setuptools, can often be a pile of monkies. pip, while also with its fair share of issues, _is_ a bit better at navigating the shallow waters at times. SO - I'd like to suggest: Instead of: python setup.py install Run: pip install . It should have the exact same result, but pip can succeed in some places where setup.py install directly can fail. Also, if you'd like to run python setup.py develop, simply run: pip install -e . Which you may not have known will run setup.py develop behind the scenes. Things this will help with: - world peace - requirements processing - global hunger - the plague Enjoy. +1 for you and all your fancy tricks! Thank you! Monty PS. The other should work. It's just sometimes it doesn't, and when it doesn't it's less my fault. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -Dolph ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Client and Policy
On 09/23/2013 03:21 PM, Doug Hellmann wrote: On Mon, Sep 23, 2013 at 4:25 AM, Flavio Percoco fla...@redhat.com mailto:fla...@redhat.com wrote: On 20/09/13 15:20 -0700, Monty Taylor wrote: On 09/20/2013 02:55 PM, Ben Nemec wrote: Not from a Gerrit perspective, but the Oslo policy is that a maintainer +1 on the code they maintain is the equivalent of a +2, so only one core is needed to approve. See https://github.com/openstack/oslo-incubator/blob/master/MAINTAINERS#L28 What if we rethought the organization just a little bit. Instead of having oslo-incubator from which we copy code, and then oslo.* that we consume as libraries, what if: - we split all oslo modules into their own repos from the start IIRC, we're planning to have a design session around these lines at the summit. I think the only issue here is figuring out where some modules belong. For example, where would we put strutils? Should we have a single repo for it or perhaps have a more generic one, say oslo.text, were we could group strutils, jsonutils and some other modules? There are plenty of single-file packages out there but I'd personally prefer grouping modules as much as possible. I agree. Another thing to consider is, what happens with Oslo modules depending on other oslo modules? I guess we would make sure all the dependencies are copied in the project as we do today but, when it comes to testing the single module, I think this could be an issue. For example, policy.py depends on fileutils, gettextutils and other oslo module which wouldn't fit in the same package, oslo.policy. This will make testing oslo.policy a real pain since we would have to copy its dependencies in its own tree as well. This is a great reason to keep everything together in a single incubator repository until a package is ready to stand on its own as a library. Libraries can easily declare dependencies to be installed for testing, but if we start copying bits of oslo around into separate git repositories then we'll all go mad trying to keep all of the repos up to date. :-) In the mean time, any review pain we have can be used as encouragement to bring the library to a point where it can be moved out of the incubator. It sounds like the primary concern is having enough keystone folks looking at reviews of the policy code, without being overwhelmed by tracking all Oslo changes. There are a couple of ways to address that. The policy code seems very tightly associated with the keystone work. There's no reason for Oslo to be the only program releasing reusable libraries. We should consider having the Keystone team manage the policy library in a repo they own. I'd love to have the Keystone middleware work the same way, instead of being in the client repo, but one step at a time. Of course, if the policy code is nearing the point where it is ready to graduate from the incubator, then maybe that suggestion is moot and we should just continue to push ahead on the path we're on now. We could have people submitting policy code to oslo-incubator add keystone-core to reviews (adding a group automatically adds its members), so they don't have to subscribe to oslo notifications. How close is the policy code to being ready to graduate? I would argue that it should graduate now. Keystone is willing to take it on as a subproject, just like the keystoneclient code is. We discussed putting it in keystoneclient, since auth_token middleware is there already. Thus, anything already using auth_token middleware already has the package. Doug - we make update.py a utility that groks copying from a directory that contains a bunch of repos - so that a person wanting to use is might have: ~/src ~/src/oslo ~/src/oslo/oslo.db ~/src/oslo/oslo.policy and then when they run update.py ~/src/oslo ~/src/nova and get the same results (the copying and name changing and whatnot) If we split modules in its own repos, I'd rather use git submodules, which would then work better. That way, we can add per-module additional core easily like we can for released oslo modules (like hacking and pbr have now) +1 Also, that would mean that moving from copying to releasing is more a matter of just making a release than it is of doing the git magic to split the repo out into a separate one and then adding the new repo to gerrit. +1 Thoughts? I like the idea overall, I'm a bit worried about how those modules would be organized. Any thoughts about the above concerns? Cheers, FF -- @flaper87 Flavio
[openstack-dev] [Nova] Review request for bp cancel-swap-volume and idempotency-client-token
Hi everyone. We registered two individual blue print. One is simple, swap-volume feature should be provide cancelling functionality. Another is a bit complicated, OpenStack API should be support API idempotency. - Cancelling a swap volume https://blueprints.launchpad.net/nova/+spec/cancel-swap-volume - Idempotency for OpenStack API https://blueprints.launchpad.net/nova/+spec/idempotentcy-client-token Please check and review these. Best Regards, /** Takahiro Shida Cheif Consultant NTTDATA INTELLILINK Phone: +81 3 5843 6880 Mail: sh...@intellilink.co.jp */ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] On the usage of pip vs. setup.py install
I ran that but world peace didn't happen. Where can I get my refund? Sent from my really tiny device... On Sep 23, 2013, at 6:47 PM, Monty Taylor mord...@inaugust.com wrote: tl;dr - easy_install sucks, so use pip It is common practice in python to run: python setup.py install or python setup.py develop So much so that we spend a giant amount of effort to make sure that those always work. Fortunately for us, the underlying mechanism, setuptools, can often be a pile of monkies. pip, while also with its fair share of issues, _is_ a bit better at navigating the shallow waters at times. SO - I'd like to suggest: Instead of: python setup.py install Run: pip install . It should have the exact same result, but pip can succeed in some places where setup.py install directly can fail. Also, if you'd like to run python setup.py develop, simply run: pip install -e . Which you may not have known will run setup.py develop behind the scenes. Things this will help with: - world peace - requirements processing - global hunger - the plague Enjoy. Monty PS. The other should work. It's just sometimes it doesn't, and when it doesn't it's less my fault. ___ 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] On the usage of pip vs. setup.py install
But I got suddenly full. Interesting thing that is. Sent from my digital shackles On Sep 23, 2013, at 7:16 PM, Joshua Harlow harlo...@yahoo-inc.com wrote: I ran that but world peace didn't happen. Where can I get my refund? Sent from my really tiny device... On Sep 23, 2013, at 6:47 PM, Monty Taylor mord...@inaugust.com wrote: tl;dr - easy_install sucks, so use pip It is common practice in python to run: python setup.py install or python setup.py develop So much so that we spend a giant amount of effort to make sure that those always work. Fortunately for us, the underlying mechanism, setuptools, can often be a pile of monkies. pip, while also with its fair share of issues, _is_ a bit better at navigating the shallow waters at times. SO - I'd like to suggest: Instead of: python setup.py install Run: pip install . It should have the exact same result, but pip can succeed in some places where setup.py install directly can fail. Also, if you'd like to run python setup.py develop, simply run: pip install -e . Which you may not have known will run setup.py develop behind the scenes. Things this will help with: - world peace - requirements processing - global hunger - the plague Enjoy. Monty PS. The other should work. It's just sometimes it doesn't, and when it doesn't it's less my fault. ___ 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] [heat] [scheduler] Bringing things together for Icehouse
I was not trying to raise issues of geographic dispersion and other higher level structures, I think the issues I am trying to raise are relevant even without them. This is not to deny the importance, or relevance, of higher levels of structure. But I would like to first respond to the discussion that I think is relevant even without them. I think it is valuable for OpenStack to have a place for holistic infrastructure scheduling. I am not the only one to argue for this, but I will give some use cases. Consider Hadoop, which stresses the path between Compute and Block Storage. In the usual way of deploying and configuring Hadoop, you want each data node to be using directly attached storage. You could address this by scheduling one of those two services first, and then the second with constraints from the first --- but the decisions made by the first could paint the second into a corner. It is better to be able to schedule both jointly. Also consider another approach to Hadoop, in which the block storage is provided by a bank of storage appliances that is equidistant (in networking terms) from all the Compute. In this case the Storage and Compute scheduling decisions have no strong interaction --- but the Compute scheduling can interact with the network (you do not want to place Compute in a way that overloads part of the network). Once a holistic infrastructure scheduler has made its decisions, there is then a need for infrastructure orchestration. The infrastructure orchestration function is logically downstream from holistic scheduling. I do not favor creating a new and alternate way of doing infrastructure orchestration in this position. Rather I think it makes sense to use essentially today's heat engine. Today Heat is the only thing that takes a holistic view of patterns/topologies/templates, and there are various pressures to expand the mission of Heat. A marquee expansion is to take on software orchestration. I think holistic infrastructure scheduling should be downstream from the preparatory stage of software orchestration (the other stage of software orchestration is the run-time action in and supporting the resources themselves). There are other pressures to expand the mission of Heat too. This leads to conflicting usages for the word heat: it can mean the infrastructure orchestration function that is the main job of today's heat engine, or it can mean the full expanded mission (whatever you think that should be). I have been mainly using heat in that latter sense, but I do not really want to argue over naming of bits and assemblies of functionality. Call them whatever you want. I am more interested in getting a useful arrangement of functionality. I have updated my picture at https://docs.google.com/drawings/d/1Y_yyIpql5_cdC8116XrBHzn6GfP_g0NHTTG_W4o0R9U --- do you agree that the arrangement of functionality makes sense? Thanks, Mike___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] [scheduler] Bringing things together for Icehouse
Someone earlier asked for greater clarity about infrastructure orchestration, so here is my view. I see two main issues: (1) deciding the order in which to do things, and (2) doing them in an acceptable order. That's an oversimplified wording because, in general, some parallelism is possible. In general, the set of things to do is constrained by a partial order --- and that partial order comes from two sources. One is the nature of the downstream APIs. For examples, you can not attach a volume or floating IP address to a VM until after both have been created. The other source of ordering constraints is upstream decision makers. Decisions made upstream are conveyed into today's heat engine by data dependencies between resources in a heat template. The heat engine is not making those decisions. It is not a source of important ordering constraints. When the ordering constraints actually allow some parallelism --- they do not specify a total order --- the heat engine has freedom in which of that parallelism to exploit vs flatten into sequential ordering. What today's heat engine does is make its available choices about that and issue the operations, keeping track of IDs and outcomes. I have been using the term infrastructure orchestration to refer to this latter job (issuing infrastructure operations with acceptable ordering/parallelism), not the decision-making of upstream agents. This might be confusing; I think the plain English meaning of orchestration suggests decision-making as well as execution. Regards, Mike___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] dnsmasq process wasn't created after added a network
Hi,
I misunderstood.
dnsmasq process was created when VM port, not a network, was added.
Thanks,
Kaneko
2013/9/20 Yoshihiro Kaneko ykaneko0...@gmail.com:
Hello,
I tried latest devstack (master branch).
And I created a network, but dnsmasq process for the network wasn't created.
localrc I used is as follows:
--
HOST_NAME=$(hostname)
SERVICE_HOST=192.168.1.10
disable_service n-net
enable_service q-svc q-agt q-dhcp q-l3 q-meta neutron
Q_HOST=$SERVICE_HOST
MYSQL_HOST=$SERVICE_HOST
RABBIT_HOST=$SERVICE_HOST
GLANCE_HOSTPORT=$SERVICE_HOST:9292
KEYSTONE_AUTH_HOST=$SERVICE_HOST
KEYSTONE_SERVICE_HOST=$SERVICE_HOST
MYSQL_PASSWORD=mysql
RABBIT_PASSWORD=rabbit
SERVICE_TOKEN=service
SERVICE_PASSWORD=admin
SERVICE_TENANT_NAME=service
ADMIN_PASSWORD=admin
RECLONE=yes
--
There is dnsmasq process for initial network (private) after stack.sh started.
--
$ neutron net-list
+--+-+--+
| id | name| subnets
|
+--+-+--+
| b2c2cc34-d349-4a2d-b153-f4cd0d357d3d | public |
0aad0524-12b3-4ec9-9c4b-c592570a5711 172.24.4.224/28 |
| c2b46689-d1a4-40d0-b0d5-103582980eea | private |
09aa0f86-eeeb-4324-91b0-233d336a29d0 10.0.0.0/24 |
+--+-+--+
$ neutron subnet-list
+--++-+--+
| id | name | cidr
| allocation_pools |
+--++-+--+
| 09aa0f86-eeeb-4324-91b0-233d336a29d0 | private-subnet | 10.0.0.0/24
| {start: 10.0.0.2, end: 10.0.0.254} |
| 0aad0524-12b3-4ec9-9c4b-c592570a5711 | public-subnet |
172.24.4.224/28 | {start: 172.24.4.226, end: 172.24.4.238} |
+--++-+--+
$ neutron port-list -c fixed_ips -c device_owner
+-+--+
| fixed_ips
| device_owner |
+-+--+
| {subnet_id: 09aa0f86-eeeb-4324-91b0-233d336a29d0, ip_address:
10.0.0.2} | network:dhcp |
| {subnet_id: 0aad0524-12b3-4ec9-9c4b-c592570a5711, ip_address:
172.24.4.226} | network:router_gateway |
| {subnet_id: 09aa0f86-eeeb-4324-91b0-233d336a29d0, ip_address:
10.0.0.1} | network:router_interface |
+-+--+
$ ps ax | grep dnsmasq
5864 ?S 0:00 dnsmasq --no-hosts --no-resolv
--strict-order --bind-interfaces --interface=tap7d7f5c08-61
--except-interface=lo
--pid-file=/opt/stack/data/neutron/dhcp/c2b46689-d1a4-40d0-b0d5-103582980eea/pid
--dhcp-hostsfile=/opt/stack/data/neutron/dhcp/c2b46689-d1a4-40d0-b0d5-103582980eea/host
--dhcp-optsfile=/opt/stack/data/neutron/dhcp/c2b46689-d1a4-40d0-b0d5-103582980eea/opts
--leasefile-ro --dhcp-range=set:tag0,10.0.0.0,static,86400s
--dhcp-lease-max=256 --conf-file= --domain=openstacklocal
--
Then, I added a new network, subnet and router, but dnsmasq process
wasn't added.
--
$ neutron net-create private2
Created a new network:
+---+--+
| Field | Value|
+---+--+
| admin_state_up| True |
| id| 99341220-b12d-4dd0-af96-19a4915e3a03 |
| name | private2 |
| provider:network_type | local|
| provider:physical_network | |
| provider:segmentation_id | |
| shared| False|
| status| ACTIVE |
| subnets | |
| tenant_id | 818d0e9c0ae94f43bd6d65a69b6f2e17 |
+---+--+
$ neutron subnet-create --ip-version 4 --gateway 11.0.0.1 private2 11.0.0.0/24
Created a new subnet:
+--++
| Field|
Re: [openstack-dev] On the usage of pip vs. setup.py install
I wonder who got the plague if u got the food :-/ Sent from my really tiny device... On Sep 23, 2013, at 8:07 PM, Michael Basnight mbasni...@gmail.com wrote: But I got suddenly full. Interesting thing that is. Sent from my digital shackles On Sep 23, 2013, at 7:16 PM, Joshua Harlow harlo...@yahoo-inc.com wrote: I ran that but world peace didn't happen. Where can I get my refund? Sent from my really tiny device... On Sep 23, 2013, at 6:47 PM, Monty Taylor mord...@inaugust.com wrote: tl;dr - easy_install sucks, so use pip It is common practice in python to run: python setup.py install or python setup.py develop So much so that we spend a giant amount of effort to make sure that those always work. Fortunately for us, the underlying mechanism, setuptools, can often be a pile of monkies. pip, while also with its fair share of issues, _is_ a bit better at navigating the shallow waters at times. SO - I'd like to suggest: Instead of: python setup.py install Run: pip install . It should have the exact same result, but pip can succeed in some places where setup.py install directly can fail. Also, if you'd like to run python setup.py develop, simply run: pip install -e . Which you may not have known will run setup.py develop behind the scenes. Things this will help with: - world peace - requirements processing - global hunger - the plague Enjoy. Monty PS. The other should work. It's just sometimes it doesn't, and when it doesn't it's less my fault. ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
