[openstack-dev] 答复: [Neutron] Auth token in context
Hello, Kevin
The leakage risk may be one of the design purpose. But Nova/Cinder has already
stored the token into the context, because Nova needs to access
Neutron.Cinder.Glance, And Cinder interact with Glance
For Neutron, I think why the token has not been passed to the context, is
because that Neutron only reactively provide service (exactly PORT ) to Nova
currently, so Neutron has not call other services' API by using the token.
If the underlying agent or plugin wants to use the token, then the requirement
will be asked by somebody.
BR
Joe
发件人: Kevin Benton [blak...@gmail.com]
发送时间: 2014年7月19日 4:23
收件人: OpenStack Development Mailing List (not for usage questions)
主题: Re: [openstack-dev] [Neutron] Auth token in context
I suspect it was just excluded since it is authenticating information and there
wasn't a good use case to pass it around everywhere in the context where it
might be leaked into logs or other network requests unexpectedly.
On Fri, Jul 18, 2014 at 1:10 PM, Phillip Toohill
phillip.tooh...@rackspace.commailto:phillip.tooh...@rackspace.com wrote:
It was for more of a potential use to query another service. Don't think well
go this route though, but was curious why it was one of the only values not
populated even though there's a field for it.
From: Kevin Benton blak...@gmail.commailto:blak...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Friday, July 18, 2014 2:16 PM
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Auth token in context
What are you trying to use the token to do?
On Fri, Jul 18, 2014 at 9:16 AM, Phillip Toohill
phillip.tooh...@rackspace.commailto:phillip.tooh...@rackspace.com wrote:
Excellent! Thank you for the response, I figured it was possible, just
concerned me to why everything else made it to context except for the
token.
So to be clear, you agree that it should at least be passed to context and
because its not could be deemed a bug?
Thank you
On 7/18/14 2:03 AM, joehuang
joehu...@huawei.commailto:joehu...@huawei.com wrote:
Hello, Phillip.
Currently, Neutron did not pass the token to the context. But Nova/Cinder
did that. It's easy to do that, just 'copy' from Nova/Cinder.
1. How Nova/Cinder did that
class NovaKeystoneContext(wsgi.Middleware)
///or CinderKeystoneContext for cinder
auth_token = req.headers.get('X_AUTH_TOKEN',
req.headers.get('X_STORAGE_TOKEN'))
ctx = context.RequestContext(user_id,
project_id,
user_name=user_name,
project_name=project_name,
roles=roles,
auth_token=auth_token,
remote_address=remote_address,
service_catalog=service_catalog)
2. Neutron not passed token. Also not good for the third part network
infrastructure to integrate the authentication with KeyStone.
class NeutronKeystoneContext(wsgi.Middleware)
.
# token not get from the header and not passed to context. Just
change here like what Nova/Cinder did.
context.Context(user_id, tenant_id, roles=roles,
user_name=user_name,
tenant_name=tenant_name,
request_id=req_id)
req.environ['neutron.context'] = ctx
I think I'd better to report a bug for your case.
Best Regards
Chaoyi Huang ( Joe Huang )
-邮件原件-
发件人: Phillip Toohill
[mailto:phillip.tooh...@rackspace.commailto:phillip.tooh...@rackspace.com]
发送时间: 2014年7月18日 14:07
收件人: OpenStack Development Mailing List (not for usage questions)
主题: [openstack-dev] [Neutron] Auth token in context
Hello all,
I am wondering how to get the auth token from a user request passed down
to the context so it can potentially be used by the plugin or driver?
Thank you
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
___
OpenStack-dev mailing list
Re: [openstack-dev] 答复: [Neutron] Auth token in context
That makes sense. Shouldn't we wait for something to require it before
adding it though?
On Sat, Jul 19, 2014 at 11:41 PM, joehuang joehu...@huawei.com wrote:
Hello, Kevin
The leakage risk may be one of the design purpose. But Nova/Cinder has
already stored the token into the context, because Nova needs to access
Neutron.Cinder.Glance, And Cinder interact with Glance
For Neutron, I think why the token has not been passed to the context, is
because that Neutron only reactively provide service (exactly PORT ) to
Nova currently, so Neutron has not call other services' API by using the
token.
If the underlying agent or plugin wants to use the token, then the
requirement will be asked by somebody.
BR
Joe
--
*发件人:* Kevin Benton [blak...@gmail.com]
*发送时间:* 2014年7月19日 4:23
*收件人:* OpenStack Development Mailing List (not for usage questions)
*主题:* Re: [openstack-dev] [Neutron] Auth token in context
I suspect it was just excluded since it is authenticating information
and there wasn't a good use case to pass it around everywhere in the
context where it might be leaked into logs or other network requests
unexpectedly.
On Fri, Jul 18, 2014 at 1:10 PM, Phillip Toohill
phillip.tooh...@rackspace.com wrote:
It was for more of a potential use to query another service. Don't
think well go this route though, but was curious why it was one of the only
values not populated even though there's a field for it.
From: Kevin Benton blak...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: Friday, July 18, 2014 2:16 PM
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Auth token in context
What are you trying to use the token to do?
On Fri, Jul 18, 2014 at 9:16 AM, Phillip Toohill
phillip.tooh...@rackspace.com wrote:
Excellent! Thank you for the response, I figured it was possible, just
concerned me to why everything else made it to context except for the
token.
So to be clear, you agree that it should at least be passed to context
and
because its not could be deemed a bug?
Thank you
On 7/18/14 2:03 AM, joehuang joehu...@huawei.com wrote:
Hello, Phillip.
Currently, Neutron did not pass the token to the context. But
Nova/Cinder
did that. It's easy to do that, just 'copy' from Nova/Cinder.
1. How Nova/Cinder did that
class NovaKeystoneContext(wsgi.Middleware)
///or CinderKeystoneContext for cinder
auth_token = req.headers.get('X_AUTH_TOKEN',
req.headers.get('X_STORAGE_TOKEN'))
ctx = context.RequestContext(user_id,
project_id,
user_name=user_name,
project_name=project_name,
roles=roles,
auth_token=auth_token,
remote_address=remote_address,
service_catalog=service_catalog)
2. Neutron not passed token. Also not good for the third part network
infrastructure to integrate the authentication with KeyStone.
class NeutronKeystoneContext(wsgi.Middleware)
.
# token not get from the header and not passed to context. Just
change here like what Nova/Cinder did.
context.Context(user_id, tenant_id, roles=roles,
user_name=user_name,
tenant_name=tenant_name,
request_id=req_id)
req.environ['neutron.context'] = ctx
I think I'd better to report a bug for your case.
Best Regards
Chaoyi Huang ( Joe Huang )
-邮件原件-
发件人: Phillip Toohill [mailto:phillip.tooh...@rackspace.com]
发送时间: 2014年7月18日 14:07
收件人: OpenStack Development Mailing List (not for usage questions)
主题: [openstack-dev] [Neutron] Auth token in context
Hello all,
I am wondering how to get the auth token from a user request passed down
to the context so it can potentially be used by the plugin or driver?
Thank you
___
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
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] [Spec freeze exception] VMware DVS support
Hi, I would like to propose the following for spec freeze exception: * https://review.openstack.org/#/c/105369 This is an umbrella spec for a number of VMware DVS support specs. Each has its own unique use case and will enable a lot of existing VMware DVS users to start to use OpenStack. For https://review.openstack.org/#/c/102720/ we have the following which we can post when the internal CI for the NSX-v is ready (we are currently working on this): - core plugin functionality - layer 3 support - security group support Thanks Gary ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] Image tagging
Hi!
I think it would be usefull to share the original vision on tagging that we
had back in 0.4 era when it was introduced.
Tagging was supposed to be JSON image metadata with extendable scheme.
Workflow should be able to both utilize that metadata and impose some
constraints on it. That feature was never really designed so I cannot tell
exactly how this JSON should work or look like. As far as I see it it can
contain:
1. Operating system information. For example os: { family: Linux,
name: Ubuntu, version: 12.04, arch: x86_x64 } (this also may be
encoded as a single string)
Workflows (MuranoPL contracts) need to be able to express requirements
based on those attributes. For example
image:
Contract($.class(Image).check($.family = Linux and $.arch = x86)
In UI only those images that matches such contract should be displayed.
2. Human readable image title Ubuntu Linux 12.04 x86
3. Information about built-in software for image-based deployment. Not sure
exactly what information is needed. Meybe even portion of Object Model so
that if such image is used Murano environment will automatically recocnize
and incorporate that application like it was added by user to be installed
on clean instance. This will allow using of pre-build images with
preinstalled software (e.g. speed up deployment) but will make it
transparent for the user so that this software could be managed as well as
applications that user choses to install
4. Minimal hardware requirement for the image. Murano could use that
information to guarantee that user will not select flavor that is too small
for that operating system.
5. General-purposed tags
We need to think how this concept fits into our roadmap and new Glance
design (probably there are other projects that can benefit from extended
image metadata) before chosing one of your approaches
Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis
sla...@mirantis.com
On Fri, Jul 18, 2014 at 6:46 PM, McLellan, Steven steve.mclel...@hp.com
wrote:
Hi,
Images that can be used for package deployment have to be tagged in glance
in order to enable the UI to filter the list of images to present to a user
(and potentially preselect). Currently the tags are defined in the
dashboard code (images/forms.py) which makes things very inflexible; if I
can upload an image and a package that consumes that image, I don’t want to
have to make a code change to use it.
Anyone who can upload images should also be able to specify tags for them.
There is also the question of whether a user should be allowed to tag
images that don’t belong to them (e.g. a shared image used by a private
package), but I think that can be punted down the road somewhat.
I think this needs to be more dynamic, and if that’s agreed upon, there
are a couple of approaches:
1) Store allowed tags in the database, and allow administrators to
add to that list. Ordinary users would likely not be able to create tags,
though they could use pre-defined ones for images they owned.
2) Have some public tags, but also allow user-specified tags for
private packages. I think this leads to all sorts of tricky edge cases
3) Allow freeform tags (i.e. don’t provide any hints). Since there’s
no formal link between the tag that a package looks for and the tags
currently defined in code, this wouldn’t make anything more susceptible to
inaccuracies
It would also be worth considering if there’s value allowing multiple tags
per image (I’m on the fence).
Personally, I think that 1) would be an improvement over the current
situation that’s reasonably easy to implement; that would allow the bare
minimum of flexibility without requiring much extra design. The other
options would perhaps be a longer term goal.
Thoughts? If there’s general agreement I will turn this into a blueprint.
Steve
___
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] [Neutron][LBaaS] TLS capability - certificates data persistency
Hi folks, In a current version of TLS capabilities RST certificate SubjectCommonName and SubjectAltName information is cached in a database. This may be not necessary and here is why: 1. TLS containers are immutable, meaning once a container was associated to a listener and was validated, it's not necessary to validate the container anymore. This is relevant for both, default container and containers used for SNI. 2. LBaaS front-end API can check if TLS containers ids were changed for a listener as part of an update operation. Validation of containers will be done for new containers only. This is stated in Performance Impact section of the RST, excepting the last statement that proposes persistency for SCN and SAN. 3. Any interaction with Barbican API for getting containers data will be performed via a common module API only. This module's API is mentioned in SNI certificates list management section of the RST. 4. In case when driver really needs to extract certificate information prior to the back-end system provisioning, it will do it via the common module API. 5. Back-end provisioning system may cache any certificate data, except private key, in case of a specific need of the vendor. IMO, There is no real need to store certificates data in Neutron database and manage its life cycle. Does anyone sees a reason why caching certificates' data in Neutron database is critical? Thank you, Evg ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Milestone and Due Dates
Hi,
Please note that if the following will not get approved this week they will not
be done in Juno which is a pity considering their almost final state.
https://review.openstack.org/#/c/98640/ - TLS termination
https://review.openstack.org/#/c/99709/ - L7 Content Switching
Please see if there is anything really critical at this stage that can't be
commented later during the code review.
Otherwise, please review and +1 so we can get final approval from Neutron cores.
Thanks,
-Sam.
-Original Message-
From: Kyle Mestery [mailto:mest...@mestery.com]
Sent: Saturday, July 19, 2014 5:52 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Milestone and Due Dates
On Fri, Jul 18, 2014 at 4:40 PM, Jorge Miramontes
jorge.miramon...@rackspace.com wrote:
Hey Kyle (and anyone else that may know the answers to my questions),
There are several blueprints that don't have Juno milestones attached
to them and was wondering if we could assign them so the broader
community is aware of the work the LBaaS folks are working on. These
are the blueprints that are currently being worked on but do not have an
assigned milestone:
https://blueprints.launchpad.net/neutron/+spec/lbaas-ref-impl-tls-supp
ort
(no milestone)
https://blueprints.launchpad.net/neutron/+spec/lbaas-ssl-termination ('next'
milestone. Not sure if this means juno-2 or juno-3)
https://blueprints.launchpad.net/neutron/+spec/lbaas-l7-rules (no
milestone)
https://blueprints.launchpad.net/neutron/+spec/neutron-flavor-framewor
k (no
milestone)
https://blueprints.launchpad.net/neutron/+spec/lbaas-l7-rules (no
milestone)
These do not have a milestone set in LP yet because the specs are not approved.
It's unclear if all of these will be approved for Juno-3 at this point, though
I suspect at least a few will be. I'm actively reviewing final specs for
approval before Spec Approval Deadline on Sunday, 7-20.
Also, please let me know if I left something out everyone.
Lastly, what are the definitive spec/implementation dates that the
LBaaS community should be aware of? A lot of us are confused on exact
dates and I wanted to make sure we were all on the same page so that
we can put resources on items that are more time sensitive.
Per above, SAD is this Sunday. The Juno release schedule is on the wiki here
[1].
Thanks,
Kyle
[1] https://wiki.openstack.org/wiki/Juno_Release_Schedule
Cheers,
--Jorge
___
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] [Neutron][LBaaS] Milestone and Due Dates
Adding Radware v2 driver design doc:
https://review.openstack.org/#/c/105669/
-Original Message-
From: Samuel Bercovici [mailto:samu...@radware.com]
Sent: Sunday, July 20, 2014 2:58 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Milestone and Due Dates
Importance: High
Hi,
Please note that if the following will not get approved this week they will not
be done in Juno which is a pity considering their almost final state.
https://review.openstack.org/#/c/98640/ - TLS termination
https://review.openstack.org/#/c/99709/ - L7 Content Switching
Please see if there is anything really critical at this stage that can't be
commented later during the code review.
Otherwise, please review and +1 so we can get final approval from Neutron cores.
Thanks,
-Sam.
-Original Message-
From: Kyle Mestery [mailto:mest...@mestery.com]
Sent: Saturday, July 19, 2014 5:52 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Milestone and Due Dates
On Fri, Jul 18, 2014 at 4:40 PM, Jorge Miramontes
jorge.miramon...@rackspace.com wrote:
Hey Kyle (and anyone else that may know the answers to my questions),
There are several blueprints that don't have Juno milestones attached
to them and was wondering if we could assign them so the broader
community is aware of the work the LBaaS folks are working on. These
are the blueprints that are currently being worked on but do not have an
assigned milestone:
https://blueprints.launchpad.net/neutron/+spec/lbaas-ref-impl-tls-supp
ort
(no milestone)
https://blueprints.launchpad.net/neutron/+spec/lbaas-ssl-termination ('next'
milestone. Not sure if this means juno-2 or juno-3)
https://blueprints.launchpad.net/neutron/+spec/lbaas-l7-rules (no
milestone)
https://blueprints.launchpad.net/neutron/+spec/neutron-flavor-framewor
k (no
milestone)
https://blueprints.launchpad.net/neutron/+spec/lbaas-l7-rules (no
milestone)
These do not have a milestone set in LP yet because the specs are not approved.
It's unclear if all of these will be approved for Juno-3 at this point, though
I suspect at least a few will be. I'm actively reviewing final specs for
approval before Spec Approval Deadline on Sunday, 7-20.
Also, please let me know if I left something out everyone.
Lastly, what are the definitive spec/implementation dates that the
LBaaS community should be aware of? A lot of us are confused on exact
dates and I wanted to make sure we were all on the same page so that
we can put resources on items that are more time sensitive.
Per above, SAD is this Sunday. The Juno release schedule is on the wiki here
[1].
Thanks,
Kyle
[1] https://wiki.openstack.org/wiki/Juno_Release_Schedule
Cheers,
--Jorge
___
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
[openstack-dev] Zuul trigger not starting Jenkins jobs
all, Need some pointers on debugging what the issue is. its not very convenient for me to be on the IRC due to timezone issues, so hoping the mailing list is a good next best option.. when i post a patch on the sandbox project, i see a review indicating my system is starting 'check' jobs, but i dont see any activity in Jenkins for the job. i can run the job manually from the master. tia! daya - output from review.openstack.org - IBM Neutron Testing Jul 14 3:33 PM Patch Set 1: Starting check jobs. http://127.0.0.1/zuul/status output log from Zuul debug- Paste #86642 | LodgeIt! Paste #86642 | LodgeIt! debug log - 2014-07-16 07:57:57,077 INFO zuul.Gerrit: Updating information for 106722,1 2014-07-16 07:57:57,936 DEBUG zuul.Gerrit: Change Change 0x7f0f4e5d64d0 106722,1 status: NEW 2014-07-16 07:57:57,936 DEBUG zuul.Scheduler: Adding trigger event: TriggerEvent... View on paste.openstack.org Preview by Yahoo (configuration shows the job mapping properly, and its receiving the triggers from the upstram, but these are not firing any Jenkins jobs) The Jenkins master connection to Gearman is showing status as ok. gearman status command output - status build:noop-check-communication:master 0 0 2 build:dsvm-tempest-full 0 0 2 build:dsvm-tempest-full:devstack_slave 0 0 2 merger:merge 0 0 1 build:ibm-dsvm-tempest-full 0 0 2 zuul:get_running_jobs 0 0 1 set_description:9.126.153.171 0 0 1 build:ibm-dsvm-tempest-full:devstack_slave 0 0 2 stop:9.126.153.171 0 0 1 zuul:promote 0 0 1 build:noop-check-communication 0 0 2 zuul:enqueue 0 0 1 merger:update 0 0 1___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron][third-party] Embrane Plugin/CI status
Hello everybody, Given the removal of the ovs core plugin, the embrane plugin was updated to use ml2 as a dependency[0], Because of this the CI will not be voting on other changesets until [0] gets merged. Regards, Ignacio [0]https://review.openstack.org/#/c/108226/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] os-refresh-config run frequency
On Thu, 2014-07-17 at 15:54 +0100, Michael Kerrin wrote: On Thursday 26 June 2014 12:20:30 Clint Byrum wrote: Excerpts from Macdonald-Wallace, Matthew's message of 2014-06-26 04:13:31 -0700: Hi all, I've been working more and more with TripleO recently and whilst it does seem to solve a number of problems well, I have found a couple of idiosyncrasies that I feel would be easy to address. My primary concern lies in the fact that os-refresh-config does not run on every boot/reboot of a system. Surely a reboot *is* a configuration change and therefore we should ensure that the box has come up in the expected state with the correct config? This is easily fixed through the addition of an @reboot entry in /etc/crontab to run o-r-c or (less easily) by re-designing o-r-c to run as a service. My secondary concern is that through not running os-refresh-config on a regular basis by default (i.e. every 15 minutes or something in the same style as chef/cfengine/puppet), we leave ourselves exposed to someone trying to make a quick fix to a production node and taking that node offline the next time it reboots because the config was still left as broken owing to a lack of updates to HEAT (I'm thinking a quick change to allow root access via SSH during a major incident that is then left unchanged for months because no-one updated HEAT). There are a number of options to fix this including Modifying os-collect-config to auto-run os-refresh-config on a regular basis or setting os-refresh-config to be its own service running via upstart or similar that triggers every 15 minutes I'm sure there are other solutions to these problems, however I know from experience that claiming this is solved through education of users or (more severely!) via HR is not a sensible approach to take as by the time you realise that your configuration has been changed for the last 24 hours it's often too late! So I see two problems highlighted above. 1) We don't re-assert ephemeral state set by o-r-c scripts. You're right, and we've been talking about it for a while. The right thing to do is have os-collect-config re-run its command on boot. I don't think a cron job is the right way to go, we should just have a file in /var/run that is placed there only on a successful run of the command. If that file does not exist, then we run the command. I've just opened this bug in response: https://bugs.launchpad.net/os-collect-config/+bug/1334804 I have been looking into bug #1334804 and I have a review up to resolve it. I want to highlight something. Currently on a reboot we start all services via upstart (on debian anyways) and there have been quite a lot of issues around this - missing upstart scripts and timing issues. I don't know the issues on fedora. So with a fix to #1334804, on a reboot upstart will start all the services first (with potentially out-of-date configuration), then o-c-c will start o-r-c and will now configure all services and restart them or start them if upstart isn't configured properly. I would like to turn off all boot scripts for services we configure and leave all this to o-r-c. I think this will simplify things and put us in control of starting services. I believe that it will also narrow the gap between fedora and debian or debian and debian so what works on one should work on the other and make it easier for developers. I'm not sold on this approach. At the very least I think we want to make this optional because not all deployments may want to have o-r-c be the central service starting agent. So I'm opposed to this being our (only!) default... The job of o-r-c in this regard is to assert state... which to me means making sure that a service is configured correctly (config files, set to start on boot, and initially started). Requiring o-r-c to be the service starting agent (always) is beyond the scope of the o-r-c tool. If people want to use it in that mode I think having an *option* to do this is fine. I don't think it should be required though. Furthermore I don't think we should get into the habit of writing our elements in such a matter that things no longer start on boot without o-r-c in the mix. I do think we can solve these problems. But taking a hardwired prescriptive approach is not good here... Having the ability to service nova-api stop|start|restart is very handy but this will be a manually thing and I intend to leave that there. What do people think and how best do I push this forward. I feel that this leads into the the re-assert-system-state spec but mainly I think this is a bug and doesn't require a spec. I will be at the tripleo mid-cycle meetup next and willing to discuss this
Re: [openstack-dev] [TripleO] os-refresh-config run frequency
Hi I also have some strong concerns about this. Can we get round a table this week and hash it out? Cheers, Chris On 20 Jul 2014, at 14:51, Dan Prince dpri...@redhat.com wrote: On Thu, 2014-07-17 at 15:54 +0100, Michael Kerrin wrote: On Thursday 26 June 2014 12:20:30 Clint Byrum wrote: Excerpts from Macdonald-Wallace, Matthew's message of 2014-06-26 04:13:31 -0700: Hi all, I've been working more and more with TripleO recently and whilst it does seem to solve a number of problems well, I have found a couple of idiosyncrasies that I feel would be easy to address. My primary concern lies in the fact that os-refresh-config does not run on every boot/reboot of a system. Surely a reboot *is* a configuration change and therefore we should ensure that the box has come up in the expected state with the correct config? This is easily fixed through the addition of an @reboot entry in /etc/crontab to run o-r-c or (less easily) by re-designing o-r-c to run as a service. My secondary concern is that through not running os-refresh-config on a regular basis by default (i.e. every 15 minutes or something in the same style as chef/cfengine/puppet), we leave ourselves exposed to someone trying to make a quick fix to a production node and taking that node offline the next time it reboots because the config was still left as broken owing to a lack of updates to HEAT (I'm thinking a quick change to allow root access via SSH during a major incident that is then left unchanged for months because no-one updated HEAT). There are a number of options to fix this including Modifying os-collect-config to auto-run os-refresh-config on a regular basis or setting os-refresh-config to be its own service running via upstart or similar that triggers every 15 minutes I'm sure there are other solutions to these problems, however I know from experience that claiming this is solved through education of users or (more severely!) via HR is not a sensible approach to take as by the time you realise that your configuration has been changed for the last 24 hours it's often too late! So I see two problems highlighted above. 1) We don't re-assert ephemeral state set by o-r-c scripts. You're right, and we've been talking about it for a while. The right thing to do is have os-collect-config re-run its command on boot. I don't think a cron job is the right way to go, we should just have a file in /var/run that is placed there only on a successful run of the command. If that file does not exist, then we run the command. I've just opened this bug in response: https://bugs.launchpad.net/os-collect-config/+bug/1334804 I have been looking into bug #1334804 and I have a review up to resolve it. I want to highlight something. Currently on a reboot we start all services via upstart (on debian anyways) and there have been quite a lot of issues around this - missing upstart scripts and timing issues. I don't know the issues on fedora. So with a fix to #1334804, on a reboot upstart will start all the services first (with potentially out-of-date configuration), then o-c-c will start o-r-c and will now configure all services and restart them or start them if upstart isn't configured properly. I would like to turn off all boot scripts for services we configure and leave all this to o-r-c. I think this will simplify things and put us in control of starting services. I believe that it will also narrow the gap between fedora and debian or debian and debian so what works on one should work on the other and make it easier for developers. I'm not sold on this approach. At the very least I think we want to make this optional because not all deployments may want to have o-r-c be the central service starting agent. So I'm opposed to this being our (only!) default... The job of o-r-c in this regard is to assert state... which to me means making sure that a service is configured correctly (config files, set to start on boot, and initially started). Requiring o-r-c to be the service starting agent (always) is beyond the scope of the o-r-c tool. If people want to use it in that mode I think having an *option* to do this is fine. I don't think it should be required though. Furthermore I don't think we should get into the habit of writing our elements in such a matter that things no longer start on boot without o-r-c in the mix. I do think we can solve these problems. But taking a hardwired prescriptive approach is not good here... Having the ability to service nova-api stop|start|restart is very handy but this will be a manually thing and I intend to leave that there. What do people think and how best do I push this forward. I feel that this leads into the the re-assert-system-state spec but mainly I think this is a bug and doesn't
Re: [openstack-dev] [TripleO] os-refresh-config run frequency
Sure. Put it in the agenda perhaps Tuesday morning On 20 Jul 2014 12:11, Chris Jones c...@tenshu.net wrote: Hi I also have some strong concerns about this. Can we get round a table this week and hash it out? Cheers, Chris On 20 Jul 2014, at 14:51, Dan Prince dpri...@redhat.com wrote: On Thu, 2014-07-17 at 15:54 +0100, Michael Kerrin wrote: On Thursday 26 June 2014 12:20:30 Clint Byrum wrote: Excerpts from Macdonald-Wallace, Matthew's message of 2014-06-26 04:13:31 -0700: Hi all, I've been working more and more with TripleO recently and whilst it does seem to solve a number of problems well, I have found a couple of idiosyncrasies that I feel would be easy to address. My primary concern lies in the fact that os-refresh-config does not run on every boot/reboot of a system. Surely a reboot *is* a configuration change and therefore we should ensure that the box has come up in the expected state with the correct config? This is easily fixed through the addition of an @reboot entry in /etc/crontab to run o-r-c or (less easily) by re-designing o-r-c to run as a service. My secondary concern is that through not running os-refresh-config on a regular basis by default (i.e. every 15 minutes or something in the same style as chef/cfengine/puppet), we leave ourselves exposed to someone trying to make a quick fix to a production node and taking that node offline the next time it reboots because the config was still left as broken owing to a lack of updates to HEAT (I'm thinking a quick change to allow root access via SSH during a major incident that is then left unchanged for months because no-one updated HEAT). There are a number of options to fix this including Modifying os-collect-config to auto-run os-refresh-config on a regular basis or setting os-refresh-config to be its own service running via upstart or similar that triggers every 15 minutes I'm sure there are other solutions to these problems, however I know from experience that claiming this is solved through education of users or (more severely!) via HR is not a sensible approach to take as by the time you realise that your configuration has been changed for the last 24 hours it's often too late! So I see two problems highlighted above. 1) We don't re-assert ephemeral state set by o-r-c scripts. You're right, and we've been talking about it for a while. The right thing to do is have os-collect-config re-run its command on boot. I don't think a cron job is the right way to go, we should just have a file in /var/run that is placed there only on a successful run of the command. If that file does not exist, then we run the command. I've just opened this bug in response: https://bugs.launchpad.net/os-collect-config/+bug/1334804 I have been looking into bug #1334804 and I have a review up to resolve it. I want to highlight something. Currently on a reboot we start all services via upstart (on debian anyways) and there have been quite a lot of issues around this - missing upstart scripts and timing issues. I don't know the issues on fedora. So with a fix to #1334804, on a reboot upstart will start all the services first (with potentially out-of-date configuration), then o-c-c will start o-r-c and will now configure all services and restart them or start them if upstart isn't configured properly. I would like to turn off all boot scripts for services we configure and leave all this to o-r-c. I think this will simplify things and put us in control of starting services. I believe that it will also narrow the gap between fedora and debian or debian and debian so what works on one should work on the other and make it easier for developers. I'm not sold on this approach. At the very least I think we want to make this optional because not all deployments may want to have o-r-c be the central service starting agent. So I'm opposed to this being our (only!) default... The job of o-r-c in this regard is to assert state... which to me means making sure that a service is configured correctly (config files, set to start on boot, and initially started). Requiring o-r-c to be the service starting agent (always) is beyond the scope of the o-r-c tool. If people want to use it in that mode I think having an *option* to do this is fine. I don't think it should be required though. Furthermore I don't think we should get into the habit of writing our elements in such a matter that things no longer start on boot without o-r-c in the mix. I do think we can solve these problems. But taking a hardwired prescriptive approach is not good here... Having the ability to service nova-api stop|start|restart is very handy but this will be a manually thing and I
Re: [openstack-dev] [infra] recheck no bug and comment
I agree that there are cases where a bug is overkill and it would be nice to add a note showing I did put some thought into doing the recheck no bug. Just my two cents. On Wed, 2014-07-16 at 17:07 +0100, Derek Higgins wrote: On 16/07/14 14:48, Steve Martinelli wrote: What are the benefits of doing this over looking at the existing rechecks, and if not there opening a bug and rechecking the new bug? I agree we should be using a bug number (or open one when needed), the example in the original email should have included a bug number but now that the topic has come up I think this would serve as a good way to provide a little explanation as to why somebody has not provided a bug number e.g. recheck no bug zuul was restarted Derek Regards, *Steve Martinelli* Software Developer - Openstack Keystone Core Member *Phone:*1-905-413-2851* E-mail:*_steve...@ca.ibm.com_ mailto:steve...@ca.ibm.com 8200 Warden Ave Markham, ON L6G 1C7 Canada From:Alexis Lee alex...@hp.com To:OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, Date:07/16/2014 09:19 AM Subject:[openstack-dev] [infra] recheck no bug and comment Hello, What do you think about allowing some text after the words recheck no bug? EG to include a snippet from the log showing the failure has been at least briefly investigated before attempting a recheck. EG: recheck no bug Compute node failed to spawn: 2014-07-15 12:18:09.936 | 3f1e7f32-812e-48c8-a83c-2615c4451fa6 | overcloud-NovaCompute0-zahdxwar7zlh | ERROR | - | NOSTATE | | Alexis -- Nova Engineer, HP Cloud. AKA lealexis, lxsli. ___ 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
Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects
Thanks Duncan and also Dolph, I should have made the question broader. :-) On Wed, 2014-07-16 at 13:22 +0100, Duncan Thomas wrote: On 16 July 2014 03:57, Jay S. Bryant jsbry...@electronicjungle.net wrote: John, So you have said a few times that the specs are a learning process. What do you feel with have learned thus far using specs? I'm not John, but I'm going to answer as if you'd addressed the question wider: - Specs can definitely help flesh out ideas and are much better than blueprints as a way of tracking concerns, questions, etc I feel I have better knowledge of what is being worked thanks to the specs. This may partially be because I was also involved from the summit on for the first time. They definitely are better for fleshing out ideas and discussing concerns. - We as a community are rather shy about making decisions as individuals, even low risk ones like 'Does this seem to require a spec' - if there doesn't seem to be value in a spec, don't do one unless somebody asks for one Agreed. I think we all need to be less shy about making decisions and voicing them. At least in Cinder. :-) - Not all questions can be answered at spec time, sometimes you need to go bash out some code to see what works, then circle again - Careful planning reduces velocity. No significant evidence either way as to whether it improves quality, but my gut feeling is that it does. We need to figure out what tradeoffs on either scale we're happy to make, and perhaps that answer is different based on the area of code being touched and the date (e.g. a change that doesn't affect external APIs in J-1 might need less careful planning than a change in J-3. API changes or additions need more discussion and eyes on than none-API changes) I think, through this development cycle we are starting to narrow down what really needs a spec. I think it would be good to perhaps have a Lessons Learned session at the K summit on the specs and try to better define expectations for use in the future. I feel it has slowed, or at least focused development. That has been good. - Specs are terrible for tracking work items, but no worse than blueprints Agreed. - Multiple people might choose to work on the same blueprint in parallel - this is going to happen, isn't necessarily rude and the correct solution to competing patches is entirely subjective ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [cinder] gettextutils enable_lazy not working
Recent change to how we use gettextutils [1] seem to not import _ anymore. According to the commit, enable_lazy() is suppose to *replace* gettextutils.install(), but I can't see where in the code that happens or see it actually working. I have reported a bug [2] that cinder-manage and cinder-rtstool [3] no longer work as a result. Using gettextutils.install() seems to resolve the issue or explicitly import _. Can someone who is familiar with this module please enlighten me how this is suppose to work? [1] - https://review.openstack.org/#/c/105561/4 [2] - https://bugs.launchpad.net/cinder/+bug/1345789 [3] - https://bugs.launchpad.net/cinder/+bug/1345789/comments/4 -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] gettextutils enable_lazy not working
Mike, Thanks for pointing this out. I thought I had gotten all of these and this supports the need for the hacking check I will work on. We also hit errors like this on our internal CI due to a bad merge. Anyway, I am on top of this. Will fix asap. Jay On Sun, 2014-07-20 at 15:49 -0700, Mike Perez wrote: Recent change to how we use gettextutils [1] seem to not import _ anymore. According to the commit, enable_lazy() is suppose to *replace* gettextutils.install(), but I can't see where in the code that happens or see it actually working. I have reported a bug [2] that cinder-manage and cinder-rtstool [3] no longer work as a result. Using gettextutils.install() seems to resolve the issue or explicitly import _. Can someone who is familiar with this module please enlighten me how this is suppose to work? [1] - https://review.openstack.org/#/c/105561/4 [2] - https://bugs.launchpad.net/cinder/+bug/1345789 [3] - https://bugs.launchpad.net/cinder/+bug/1345789/comments/4 -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [third-party] Zuul trigger not starting Jenkins jobs
all, Need some pointers on debugging what the issue is. its not very convenient for me to be on the IRC due to timezone issues, so hoping the mailing list is a good next best option.. when i post a patch on the sandbox project, i see a review indicating my system is starting 'check' jobs, but i dont see any activity in Jenkins for the job. i can run the job manually from the master. tia! daya - output from review.openstack.org - IBM Neutron Testing Jul 14 3:33 PM Patch Set 1: Starting check jobs. http://127.0.0.1/zuul/status output log from Zuul debug- Paste #86642 | LodgeIt! Paste #86642 | LodgeIt! debug log - 2014-07-16 07:57:57,077 INFO zuul.Gerrit: Updating information for 106722,1 2014-07-16 07:57:57,936 DEBUG zuul.Gerrit: Change Change 0x7f0f4e5d64d0 106722,1 status: NEW 2014-07-16 07:57:57,936 DEBUG zuul.Scheduler: Adding trigger event: TriggerEvent... View on paste.openstack.org Preview by Yahoo (configuration shows the job mapping properly, and its receiving the triggers from the upstram, but these are not firing any Jenkins jobs) The Jenkins master connection to Gearman is showing status as ok. gearman status command output - status build:noop-check-communication:master 0 0 2 build:dsvm-tempest-full 0 0 2 build:dsvm-tempest-full:devstack_slave 0 0 2 merger:merge 0 0 1 build:ibm-dsvm-tempest-full 0 0 2 zuul:get_running_jobs 0 0 1 set_description:9.126.153.171 0 0 1 build:ibm-dsvm-tempest-full:devstack_slave 0 0 2 stop:9.126.153.171 0 0 1 zuul:promote 0 0 1 build:noop-check-communication 0 0 2 zuul:enqueue 0 0 1 merger:update 0 0 1___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Virtio-scsi settings nova-specs exception
I just want to check my understanding -- it seems to me that this depends on a feature that's very new to libvirt (merged there 22 May 2014). Is that right? http://libvirt.org/git/?p=libvirt.git;a=commit;h=d950494129513558a303387e26a2bab057012c5e We've had some concerns about adding features to the libvirt driver for features represented only in very new versions of libvirt. https://review.openstack.org/#/c/72038/ is an example. Now, its clear to me that we don't yet have a consensus on nova-core on how to handle features depending on very new libvirts. There are certainly CI concerns at the least. So, I think approving this exception is tied up in that whole debate. Hopefully we can get that sorted out soon (and possibly unblock https://review.openstack.org/#/c/72038/ depending on the outcome). Michael On Sat, Jul 19, 2014 at 3:52 AM, Vishvananda Ishaya vishvana...@gmail.com wrote: I will also sponsor this. Vish On Jul 17, 2014, at 2:47 PM, Mike Perez thin...@gmail.com wrote: As requested from the #openstack-meeting for Nova, I'm posting my nova-spec exception proposal to the ML. Spec: https://review.openstack.org/#/c/103797/3/specs/juno/virtio-scsi-settings.rst Code: https://review.openstack.org/#/c/107650/ - Nikola Dipanov was kind to be the first core sponsor. [1] - This is an optional feature, which should make it a low risk for Nova. - The spec was posted before the spec freeze deadline. - Code change is reasonable and available now. Thank you! [1] - https://etherpad.openstack.org/p/nova-juno-spec-priorities -- Mike Perez ___ 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 -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Virtio-scsi settings nova-specs exception
On 10:21 Mon 21 Jul , Michael Still wrote: I just want to check my understanding -- it seems to me that this depends on a feature that's very new to libvirt (merged there 22 May 2014). Is that right? http://libvirt.org/git/?p=libvirt.git;a=commit;h=d950494129513558a303387e26a2bab057012c5e Yes, this was mentioned in the Nova spec itself. We've had some concerns about adding features to the libvirt driver for features represented only in very new versions of libvirt. https://review.openstack.org/#/c/72038/ is an example. Now, its clear to me that we don't yet have a consensus on nova-core on how to handle features depending on very new libvirts. There are certainly CI concerns at the least. So, I think approving this exception is tied up in that whole debate. Hopefully we can get that sorted out soon (and possibly unblock https://review.openstack.org/#/c/72038/ depending on the outcome). Michael For what it's worth, it's optional and the administrator would have to really go out of their way to enable this in two ways: * You have to be using a Cinder driver that uses the vhost connector to pass the connection data to Nova. * Glance metadata of an image has to have these options set. The review you provided with the debate raised by Dan Smith has been stale for 19 days with Daniel waiting for a reply. Should we have this listed for the next Nova meeting? -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] os-refresh-config run frequency
Excerpts from Dan Prince's message of 2014-07-20 11:51:27 -0700: On Thu, 2014-07-17 at 15:54 +0100, Michael Kerrin wrote: On Thursday 26 June 2014 12:20:30 Clint Byrum wrote: Excerpts from Macdonald-Wallace, Matthew's message of 2014-06-26 04:13:31 -0700: Hi all, I've been working more and more with TripleO recently and whilst it does seem to solve a number of problems well, I have found a couple of idiosyncrasies that I feel would be easy to address. My primary concern lies in the fact that os-refresh-config does not run on every boot/reboot of a system. Surely a reboot *is* a configuration change and therefore we should ensure that the box has come up in the expected state with the correct config? This is easily fixed through the addition of an @reboot entry in /etc/crontab to run o-r-c or (less easily) by re-designing o-r-c to run as a service. My secondary concern is that through not running os-refresh-config on a regular basis by default (i.e. every 15 minutes or something in the same style as chef/cfengine/puppet), we leave ourselves exposed to someone trying to make a quick fix to a production node and taking that node offline the next time it reboots because the config was still left as broken owing to a lack of updates to HEAT (I'm thinking a quick change to allow root access via SSH during a major incident that is then left unchanged for months because no-one updated HEAT). There are a number of options to fix this including Modifying os-collect-config to auto-run os-refresh-config on a regular basis or setting os-refresh-config to be its own service running via upstart or similar that triggers every 15 minutes I'm sure there are other solutions to these problems, however I know from experience that claiming this is solved through education of users or (more severely!) via HR is not a sensible approach to take as by the time you realise that your configuration has been changed for the last 24 hours it's often too late! So I see two problems highlighted above. 1) We don't re-assert ephemeral state set by o-r-c scripts. You're right, and we've been talking about it for a while. The right thing to do is have os-collect-config re-run its command on boot. I don't think a cron job is the right way to go, we should just have a file in /var/run that is placed there only on a successful run of the command. If that file does not exist, then we run the command. I've just opened this bug in response: https://bugs.launchpad.net/os-collect-config/+bug/1334804 I have been looking into bug #1334804 and I have a review up to resolve it. I want to highlight something. Currently on a reboot we start all services via upstart (on debian anyways) and there have been quite a lot of issues around this - missing upstart scripts and timing issues. I don't know the issues on fedora. So with a fix to #1334804, on a reboot upstart will start all the services first (with potentially out-of-date configuration), then o-c-c will start o-r-c and will now configure all services and restart them or start them if upstart isn't configured properly. I would like to turn off all boot scripts for services we configure and leave all this to o-r-c. I think this will simplify things and put us in control of starting services. I believe that it will also narrow the gap between fedora and debian or debian and debian so what works on one should work on the other and make it easier for developers. I'm not sold on this approach. At the very least I think we want to make this optional because not all deployments may want to have o-r-c be the central service starting agent. So I'm opposed to this being our (only!) default... I felt this way too. However, I'm open to it because I am worried that it is a bit idealistic without much justification for being so. We know o-r-c will be there, and really must be there. We're already saying it needs to run to assert ephemeral state, and one thing ephemeral is things started. Now, we can, and maybe even should, take a hard line long term that o-r-c does not do this. That it stores everything in system level configs that are started in the normal system boot. I _want_ this to be the case. But thus far, we've failed to assert that and things have occasionally been very broken on reboot. Short of forcing a reboot in every CI run, we're going to have trouble detecting this. So, I think we have two options: 1) O-r-c doing the asserting, with which we can more or less predict that subsequent boots will work in the same manner as the first boot. 2)
Re: [openstack-dev] Virtio-scsi settings nova-specs exception
I agree this has stalled for too long, although I feel like http://lists.openstack.org/pipermail/openstack-dev/2014-July/040421.html has progressed the topic a little. On the other hand, its been a busy patch in the cycle and I think we can get this conversation back on track now. That's why I cc'ed the main protagonists into my email on this thread. Michael On Mon, Jul 21, 2014 at 10:55 AM, Mike Perez thin...@gmail.com wrote: On 10:21 Mon 21 Jul , Michael Still wrote: I just want to check my understanding -- it seems to me that this depends on a feature that's very new to libvirt (merged there 22 May 2014). Is that right? http://libvirt.org/git/?p=libvirt.git;a=commit;h=d950494129513558a303387e26a2bab057012c5e Yes, this was mentioned in the Nova spec itself. We've had some concerns about adding features to the libvirt driver for features represented only in very new versions of libvirt. https://review.openstack.org/#/c/72038/ is an example. Now, its clear to me that we don't yet have a consensus on nova-core on how to handle features depending on very new libvirts. There are certainly CI concerns at the least. So, I think approving this exception is tied up in that whole debate. Hopefully we can get that sorted out soon (and possibly unblock https://review.openstack.org/#/c/72038/ depending on the outcome). Michael For what it's worth, it's optional and the administrator would have to really go out of their way to enable this in two ways: * You have to be using a Cinder driver that uses the vhost connector to pass the connection data to Nova. * Glance metadata of an image has to have these options set. The review you provided with the debate raised by Dan Smith has been stale for 19 days with Daniel waiting for a reply. Should we have this listed for the next Nova meeting? -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [rally][nova] boot-and-delete
The boot-and-delete.json is
NovaServers.boot_and_delete_server: [
{
args: {
flavor: {
name: ooo
},
image: {
name: ubuntu1204
},
},
runner: {
type: constant,
times:50,
concurrency:21
},
context: {
users: {
tenants: 1,
users_per_tenant:1
},
}
}
]
}
It sounds like that, the rally start an new iter, before scheduler konw that
the resource is backed to compute node. Can some one test this before?
why the scheduler be late? i set resource tracker period to 1s. But the problem
also appeared.
the scheduler in ram filter is
ram:31618 disk:339968 io_ops:0 instances:0:now:2014-07-21
10:07:19.726181:memory_mb_limit:48195.0:used_ram_mb:512:usable_ram:47683.0
host_passes /
ram:29570 disk:329728 io_ops:1 instances:1:now:2014-07-21
10:07:19.740639:memory_mb_limit:48195.0:used_ram_mb:2560:usable_ram:45635.0
host_passes /
ram:27522 disk:319488 io_ops:2 instances:2:now:2014-07-21
10:07:19.798188:memory_mb_limit:48195.0:used_ram_mb:4608:usable_ram:43587.0
host_passes /
ram:25474 disk:309248 io_ops:3 instances:3:now:2014-07-21
10:07:19.811062:memory_mb_limit:48195.0:used_ram_mb:6656:usable_ram:41539.0
host_passes /
ram:23426 disk:299008 io_ops:4 instances:4:now:2014-07-21
10:07:19.822793:memory_mb_limit:48195.0:used_ram_mb:8704:usable_ram:39491.0
host_passes /
ram:21378 disk:288768 io_ops:5 instances:5:now:2014-07-21
10:07:19.833709:memory_mb_limit:48195.0:used_ram_mb:10752:usable_ram:37443.0
host_passes /
ram:19330 disk:278528 io_ops:6 instances:6:now:2014-07-21
10:07:19.858253:memory_mb_limit:48195.0:used_ram_mb:12800:usable_ram:35395.0
host_passes /
ram:17282 disk:268288 io_ops:7 instances:7:now:2014-07-21
10:07:22.230625:memory_mb_limit:48195.0:used_ram_mb:14848:usable_ram:33347.0
host_passes /
ram:15234 disk:258048 io_ops:8 instances:8:now:2014-07-21
10:07:22.444355:memory_mb_limit:48195.0:used_ram_mb:16896:usable_ram:31299.0
host_passes /
ram:13186 disk:247808 io_ops:9 instances:9:now:2014-07-21
10:07:22.456158:memory_mb_limit:48195.0:used_ram_mb:18944:usable_ram:29251.0
host_passes /
ram:11138 disk:237568 io_ops:10 instances:10:now:2014-07-21
10:07:22.466355:memory_mb_limit:48195.0:used_ram_mb:20992:usable_ram:27203.0
host_passes /
ram:9090 disk:227328 io_ops:11 instances:11:now:2014-07-21
10:07:22.476552:memory_mb_limit:48195.0:used_ram_mb:23040:usable_ram:25155.0
host_passes /
ram:7042 disk:217088 io_ops:12 instances:12:now:2014-07-21
10:07:22.486794:memory_mb_limit:48195.0:used_ram_mb:25088:usable_ram:23107.0
host_passes /
ram:4994 disk:206848 io_ops:13 instances:13:now:2014-07-21
10:07:22.780476:memory_mb_limit:48195.0:used_ram_mb:27136:usable_ram:21059.0
host_passes /
ram:2946 disk:196608 io_ops:14 instances:14:now:2014-07-21
10:07:22.791989:memory_mb_limit:48195.0:used_ram_mb:29184:usable_ram:19011.0
host_passes /
ram:898 disk:186368 io_ops:15 instances:15:now:2014-07-21
10:07:22.944792:memory_mb_limit:48195.0:used_ram_mb:31232:usable_ram:16963.0
host_passes /
ram:-1150 disk:176128 io_ops:16 instances:16:now:2014-07-21
10:07:22.955335:memory_mb_limit:48195.0:used_ram_mb:33280:usable_ram:14915.0
host_passes /
ram:-3198 disk:165888 io_ops:17 instances:17:now:2014-07-21
10:07:22.965552:memory_mb_limit:48195.0:used_ram_mb:35328:usable_ram:12867.0
host_passes /
ram:-5246 disk:155648 io_ops:18 instances:18:now:2014-07-21
10:07:22.975790:memory_mb_limit:48195.0:used_ram_mb:37376:usable_ram:10819.0
host_passes /
ram:-7294 disk:145408 io_ops:19 instances:19:now:2014-07-21
10:07:22.986395:memory_mb_limit:48195.0:used_ram_mb:39424:usable_ram:8771.0
host_passes /
ram:-9342 disk:135168 io_ops:20 instances:20:now:2014-07-21
10:07:22.996581:memory_mb_limit:48195.0:used_ram_mb:41472:usable_ram:6723.0
host_passes /
ram:-11390 disk:268288 io_ops:12 instances:21:now:2014-07-21
10:08:30.170616:memory_mb_limit:48195.0:used_ram_mb:43520:usable_ram:4675.0
host_passes /
ram:-13438 disk:258048 io_ops:13 instances:22:now:2014-07-21
10:08:30.188967:memory_mb_limit:48195.0:used_ram_mb:45568:usable_ram:2627.0
host_passes /
ram:-15486 disk:268288 io_ops:7 instances:23:now:2014-07-21
10:09:58.839181:memory_mb_limit:48195.0:used_ram_mb:47616:usable_ram:579.0
host_passes /
ram:-15486 disk:268288 io_ops:7 instances:23:now:2014-07-21
10:09:59.432281:memory_mb_limit:48195.0:used_ram_mb:47616:usable_ram:579.0
host_passes /
ram:-15486 disk:268288 io_ops:7 instances:23:now:2014-07-21
10:10:00.658376:memory_mb_limit:48195.0:used_ram_mb:47616:usable_ram:579.0
host_passes /
ram:-15486 disk:268288 io_ops:7 instances:23:now:2014-07-21
10:10:01.138658:memory_mb_limit:48195.0:used_ram_mb:47616:usable_ram:579.0
host_passes /
ram:-15486 disk:268288 io_ops:7
Re: [openstack-dev] [cinder][nova] cinder querying nova-api
Abbass, There has been discussion around this in the past. As it would be a significant feature you should open a spec for it. Do a 'git clone https://github.com/openstack/cinder-specs. There are directions in there for actually submitting the spec. Thanks! Jay On Fri, 2014-07-18 at 09:01 +0200, Abbass MAROUNI wrote: Thanks Thomas, By cinder spec. you mean a cinder blueprint ? Where I can submit such a proposition ? Thanks, On 07/17/2014 05:20 PM, openstack-dev-requ...@lists.openstack.org wrote: You're far from the only person trying to achieve that result, there's plenty of interest in it, and a few approaches being suggested. I can't see a current cinder spec open for this, so it might be worth you starting one, you're more likely to get detailed feedback about the pitfalls there. ___ 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
Status, as I understand it: * oslo.db changes to support other mysql drivers: https://review.openstack.org/#/c/104425/ (merged) https://review.openstack.org/#/c/106928/ (awaiting oslo.db review) https://review.openstack.org/#/c/107221/ (awaiting oslo.db review) (These are sufficient to allow operators to switch connection strings and use mysqlconnector. The rest is all for our testing environment) * oslo.db change to allow testing with other mysql drivers: https://review.openstack.org/#/c/104428/ (awaiting oslo.db review) https://review.openstack.org/#/c/104447/ (awaiting oslo.db review. Ongoing discussion towards a larger rewrite of oslo.db testing instead) * Integration into jenkins environment: Blocked on getting Oracle to distribute mysql-connector via pypi. Ihar and others are having conversations with the upstream author. * Devstack change to switch to mysqlconnector for neutron: https://review.openstack.org/#/c/105209/ (marked wip) Ihar: do you want me to pick this up, or are you going to continue it once some of the above has settled? * oslo.db gate test that reproduces the deadlock with eventlet: https://review.openstack.org/#/c/104436/ (In review. Can't be submitted until gate environment is switched to mysqlconnector) Overall I'm not happy with the rate of change - but we're getting there. I look forward to getting this fixed :/ On 18 July 2014 21:45, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 14/07/14 17:03, Ihar Hrachyshka wrote: On 14/07/14 15:54, Clark Boylan wrote: On Sun, Jul 13, 2014 at 9:20 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: On 11/07/14 19:20, Clark Boylan wrote: Before we get too far ahead of ourselves mysql-connector is not hosted on pypi. Instead it is an external package link. We recently managed to remove all packages that are hosted as external package links from openstack and will not add new ones in. Before we can use mysql-connector in the gate oracle will need to publish mysql-connector on pypi properly. There is misunderstanding in our community on how we deploy db client modules. No project actually depends on any of them. We assume deployers will install the proper one and configure 'connection' string to use it. In case of devstack, we install the appropriate package from distribution packages, not pip. Correct, but for all of the other test suites (unittests) we install the db clients via pip because tox runs them and virtualenvs allowing site packages cause too many problems. See https://git.openstack.org/cgit/openstack/nova/tree/test-requirements.txt#n8 . So we do actually depend on these things being pip installable. Basically this allows devs to run `tox` and it works. Roger that, and thanks for clarification. I'm trying to reach the author and the maintainer of mysqlconnector-python to see whether I'll be able to convince him to publish the packages on pypi.python.org. I've reached the maintainer of the module, he told me he is currently working on uploading releases directly to pypi.python.org. I would argue that we should have devstack install via pip too for consistency, but that is a different issue (it is already installing all of the other python dependencies this way so why special case?). What we do is recommending a module for our users in our documentation. That said, I assume the gate is a non-issue. Correct? That said there is at least one other pure python alternative, PyMySQL. PyMySQL supports py3k and pypy. We should look at using PyMySQL instead if we want to start with a reasonable path to getting this in the gate. MySQL Connector supports py3k too (not sure about pypy though). Clark On Fri, Jul 11, 2014 at 10:07 AM, Miguel Angel Ajo Pelayo mangel...@redhat.com wrote: +1 here too, Amazed with the performance gains, x2.4 seems a lot, and we'd get rid of deadlocks. - Original Message - +1 I'm pretty excited about the possibilities here. I've had this mysqldb/eventlet contention in the back of my mind for some time now. I'm glad to see some work being done in this area. Carl On Fri, Jul 11, 2014 at 7:04 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: On 09/07/14 13:17, Ihar Hrachyshka wrote: Hi all, Multiple projects are suffering from db lock timeouts due to deadlocks deep in mysqldb library that we use to interact with mysql servers. In essence, the problem is due to missing eventlet support in mysqldb module, meaning when a db lock is encountered, the library does not yield to the next green thread, allowing other threads to eventually unlock the grabbed lock, and instead it just blocks the main thread, that eventually raises timeout exception (OperationalError). The failed operation is not retried, leaving failing request not served. In Nova, there is a
Re: [openstack-dev] [TripleO] os-refresh-config run frequency
-Original Message- From: Clint Byrum [mailto:cl...@fewbar.com] Sent: 21 July 2014 01:58 To: openstack-dev Subject: Re: [openstack-dev] [TripleO] os-refresh-config run frequency Excerpts from Dan Prince's message of 2014-07-20 11:51:27 -0700: On Thu, 2014-07-17 at 15:54 +0100, Michael Kerrin wrote: On Thursday 26 June 2014 12:20:30 Clint Byrum wrote: Excerpts from Macdonald-Wallace, Matthew's message of 2014-06-26 04:13:31 -0700: Hi all, I've been working more and more with TripleO recently and whilst it does seem to solve a number of problems well, I have found a couple of idiosyncrasies that I feel would be easy to address. My primary concern lies in the fact that os-refresh-config does not run on every boot/reboot of a system. Surely a reboot *is* a configuration change and therefore we should ensure that the box has come up in the expected state with the correct config? This is easily fixed through the addition of an @reboot entry in /etc/crontab to run o-r-c or (less easily) by re-designing o-r-c to run as a service. My secondary concern is that through not running os-refresh-config on a regular basis by default (i.e. every 15 minutes or something in the same style as chef/cfengine/puppet), we leave ourselves exposed to someone trying to make a quick fix to a production node and taking that node offline the next time it reboots because the config was still left as broken owing to a lack of updates to HEAT (I'm thinking a quick change to allow root access via SSH during a major incident that is then left unchanged for months because no-one updated HEAT). There are a number of options to fix this including Modifying os-collect-config to auto-run os-refresh-config on a regular basis or setting os-refresh-config to be its own service running via upstart or similar that triggers every 15 minutes I'm sure there are other solutions to these problems, however I know from experience that claiming this is solved through education of users or (more severely!) via HR is not a sensible approach to take as by the time you realise that your configuration has been changed for the last 24 hours it's often too late! So I see two problems highlighted above. 1) We don't re-assert ephemeral state set by o-r-c scripts. You're right, and we've been talking about it for a while. The right thing to do is have os-collect-config re-run its command on boot. I don't think a cron job is the right way to go, we should just have a file in /var/run that is placed there only on a successful run of the command. If that file does not exist, then we run the command. I've just opened this bug in response: https://bugs.launchpad.net/os-collect-config/+bug/1334804 I have been looking into bug #1334804 and I have a review up to resolve it. I want to highlight something. Currently on a reboot we start all services via upstart (on debian anyways) and there have been quite a lot of issues around this - missing upstart scripts and timing issues. I don't know the issues on fedora. So with a fix to #1334804, on a reboot upstart will start all the services first (with potentially out-of-date configuration), then o-c-c will start o-r-c and will now configure all services and restart them or start them if upstart isn't configured properly. I would like to turn off all boot scripts for services we configure and leave all this to o-r-c. I think this will simplify things and put us in control of starting services. I believe that it will also narrow the gap between fedora and debian or debian and debian so what works on one should work on the other and make it easier for developers. I'm not sold on this approach. At the very least I think we want to make this optional because not all deployments may want to have o-r-c be the central service starting agent. So I'm opposed to this being our (only!) default... I felt this way too. However, I'm open to it because I am worried that it is a bit idealistic without much justification for being so. We know o-r-c will be there, and really must be there. We're already saying it needs to run to assert ephemeral state, and one thing ephemeral is things started. Now, we can, and maybe even should, take a hard line long term that o-r- c does not do this. That it stores everything in system level configs that are started in the normal system boot. I _want_ this to be the case. But thus far, we've failed to assert
