Re: [openstack-dev] [heat][neutron] OS::Heat::AutoScalingGroup and OS::Neutron::PoolMember?
On 03/12/2014 06:34 PM, Mike Spreitzer wrote:
Has anybody exercised the case of OS::Heat::AutoScalingGroup scaling a
nested stack that includes a OS::Neutron::PoolMember? Should I expect
this to work?
This sort of thing works fine for us. It needs some patches that missed
Havana, though.
{
AWSTemplateFormatVersion: 2010-09-09,
Description: Sample webserver config,
Resources: {
LBMonitor: {
Type: OS::Neutron::HealthMonitor,
Properties: {
delay: 3,
max_retries: 5,
url_path: /_,
type: HTTP,
timeout: 10
}
},
LaunchConfig: {
Type: AWS::AutoScaling::LaunchConfiguration,
Properties: {
},
SecurityGroups: [ { Ref: SecGroup } ],
InstanceType: m1.small,
ImageId: CentOS65-1312-1
}
},
ELB: {
Type: OS::Neutron::LoadBalancer,
Properties: {
protocol_port: 8080,
pool_id: { Ref: LBPool }
}
},
ASG: {
Version: 2009-05-15,
Type: AWS::AutoScaling::AutoScalingGroup,
Properties: {
LaunchConfigurationName: { Ref: LaunchConfig },
MinSize: 1,
MaxSize: 2,
VPCZoneIdentifier: [ mumbleuuid ],
LoadBalancerNames: [ { Ref: ELB } ],
AvailabilityZones: { Fn::GetAZs: }
}
},
LBPool: {
Type: OS::Neutron::Pool,
Properties: {
lb_method: ROUND_ROBIN,
protocol: HTTP,
description: Test Pool,
subnet_id: mumbleuuid,
vip: {
protocol_port: 8080,
connection_limit: 1000,
description: Test,
name: Test
},
monitors: [ { Ref: LBMonitor } ],
name: test
}
},
SecGroup: {
Type: AWS::EC2::SecurityGroup,
Properties: {
SecurityGroupIngress: [
{
SourceSecurityGroupId: mumbleuuid,
IpProtocol: tcp,
ToPort: 8080,
FromPort: 8080
},
],
GroupDescription: Test
}
}
}
}
Cheers,
--
Stephen Gran
Senior Systems Integrator - theguardian.com
Please consider the environment before printing this email.
--
Visit theguardian.com
On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad
Save up to 57% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access.
Visit subscribe.theguardian.com
This e-mail and all attachments are confidential and may also
be privileged. If you are not the named recipient, please notify
the sender and delete the e-mail and all attachments immediately.
Do not disclose the contents to another person. You may not use
the information for any purpose, or store, or copy, it in any way.
Guardian News Media Limited is not liable for any computer
viruses or other material transmitted with or as part of this
e-mail. You should employ virus checking software.
Guardian News Media Limited
A member of Guardian Media Group plc
Registered Office
PO Box 68164
Kings Place
90 York Way
London
N1P 2AP
Registered in England Number 908396
--
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?
Hi, Given that Yuriy says explicitly 'unix socket', I dont think he means 'MQ' when he says 'RPC'. I think he just means a daemon listening on a unix socket for execution requests. This seems like a reasonably sensible idea to me. Cheers, On 07/03/14 12:52, Miguel Angel Ajo wrote: I thought of this option, but didn't consider it, as It's somehow risky to expose an RPC end executing priviledged (even filtered) commands. If I'm not wrong, once you have credentials for messaging, you can send messages to any end, even filtered, I somehow see this as a higher risk option. And btw, if we add RPC in the middle, it's possible that all those system call delays increase, or don't decrease all it'll be desirable. On 03/07/2014 10:06 AM, Yuriy Taraday wrote: Another option would be to allow rootwrap to run in daemon mode and provide RPC interface. This way Neutron can spawn rootwrap (with its CPython startup overhead) once and send new commands to be run later over UNIX socket. This way we won't need learn new language (C/C++), adopt new toolchain (RPython, Cython, whatever else) and still get secure way to run commands with root priviledges. -- Stephen Gran Senior Systems Integrator - theguardian.com Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 57% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] stored userdata
On 07/03/14 05:05, Hiroyuki Eguchi wrote: I'm envisioning a stored userdata feature. https://blueprints.launchpad.net/nova/+spec/stored-userdata Currently, OpenStack allow user to execute script or send configuration file when creating a instance by using --user-data /path/to/filename option. But,In order to use this option, All users must input userdata every time. So we need to store the userdata in database so that users can manage userdata more easily. I'm planning to develop these Nova-APIs. - nova userdata-create - nova userdata-update - nova userdata-delete - nova userdata-show - nova userdata-list Users can specify a userdata_name managed by Nova DB or /path/to/filename in --user-data option. - nova boot --user-data userdata_name or /path/to/filename ... If you have any comments or suggestion, please let me know. And please let me know if there's any discussion about this. In general, I think userdata should be WORM. It certainly is in every other cloud setup I am familiar with. This is the information fed to the instance when it boots the first time - having userdata change over time means you lose access to the original when you want to go back and retrieve it. I think this would be a regression, and be unexpected behavior. Cheers, -- Stephen Gran Senior Systems Integrator - theguardian.com Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 57% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Proposal to move from Freenode to OFTC
On 04/03/14 11:01, Thierry Carrez wrote: James E. Blair wrote: Freenode has been having a rough time lately due to a series of DDoS attacks which have been increasingly disruptive to collaboration. Fortunately there's an alternative. OFTC URL:http://www.oftc.net/ is a robust and established alternative to Freenode. It is a smaller network whose mission statement makes it a less attractive target. It's significantly more stable than Freenode and has friendly and responsive operators. The infrastructure team has been exploring this area and we think OpenStack should move to using OFTC. There is quite a bit of literature out there pointing to Freenode, like presentation slides from old conferences. We should expect people to continue to join Freenode's channels forever. I don't think staying a few weeks on those channels to redirect misled people will be nearly enough. Could we have a longer plan ? Like advertisement bots that would advise every n hours to join the right servers ? Why not just set /topic to tell people to connect to OFTC and join there? Cheers, -- Stephen Gran Senior Systems Integrator - theguardian.com Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 57% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] memoizer aka cache
Hi,
First, I think common routines are great. More DRY is always good.
Second, my personal feeling is that when you see a hard-coded in-memory
cache like this, it's probably something that should be moved to be
behind a more generic caching framework that allows for different
backends such as memcache for larger deployments.
If you're interested in something like that, I'm sure it would be useful.
Cheers,
On 23/01/14 16:07, Shawn Hartsock wrote:
I would like to have us adopt a memoizing caching library of some kind
for use with OpenStack projects. I have no strong preference at this
time and I would like suggestions on what to use.
I have seen a number of patches where people have begun to implement
their own caches in dictionaries. This typically confuses the code and
mixes issues of correctness and performance in code.
Here's an example:
We start with:
def my_thing_method(some_args):
# do expensive work
return value
... but a performance problem is detected... maybe the method is
called 15 times in 10 seconds but then not again for 5 minutes and the
return value can only logically change every minute or two... so we
end up with ...
_GLOBAL_THING_CACHE = {}
def my_thing_method(some_args):
key = key_from(some_args)
if key in _GLOBAL_THING_CACHE:
return _GLOBAL_THING_CACHE[key]
else:
# do expensive work
_GLOBAL_THING_CACHE[key] = value
return value
... which is all well and good... but now as a maintenance programmer
I need to comprehend the cache mechanism, when cached values are
invalidated, and if I need to debug the do expensive work part I
need to tease out some test that prevents the cache from being hit.
Plus I've introduced a new global variable. We love globals right?
I would like us to be able to say:
@memoize(seconds=10)
def my_thing_method(some_args):
# do expensive work
return value
... where we're clearly addressing the performance issue by
introducing a cache and limiting it's possible impact to 10 seconds
which allows for the idea that do expensive work has network calls
to systems that may change state outside of this Python process.
I'd like to see this done because I would like to have a place to
point developers to during reviews... to say: use common/memoizer or
use Bob's awesome memoizer because Bob has worked out all the cache
problems already and you can just use it instead of worrying about
introducing new bugs by building your own cache.
Does this make sense? I'd love to contribute something... but I wanted
to understand why this state of affairs has persisted for a number of
years... is there something I'm missing?
--
Stephen Gran
Senior Systems Integrator - theguardian.com
Please consider the environment before printing this email.
--
Visit theguardian.com
On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad
Save up to 57% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access.
Visit subscribe.theguardian.com
This e-mail and all attachments are confidential and may also
be privileged. If you are not the named recipient, please notify
the sender and delete the e-mail and all attachments immediately.
Do not disclose the contents to another person. You may not use
the information for any purpose, or store, or copy, it in any way.
Guardian News Media Limited is not liable for any computer
viruses or other material transmitted with or as part of this
e-mail. You should employ virus checking software.
Guardian News Media Limited
A member of Guardian Media Group plc
Registered Office
PO Box 68164
Kings Place
90 York Way
London
N1P 2AP
Registered in England Number 908396
--
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Partially Shared Networks
Hi, I don't think that's what's being asked for. Just that there be more than the current check for '(isowner of network) or (shared)' If the data point could be 'enabled for network' for a given tenant, that would be more flexible. Cheers, On 13/01/14 10:06, Mathieu Rohon wrote: Hi, This is something that we potentially could implement during the implementation of the isolated-network bp [1] Basically, on an isolated network, an ARP responder will respond to ARP request. For an L2 network which is totally isolated, ARP responder will only respond to arp-request of the gateway, other broadcast requests will be dropped (except for DHCP requests) We could enhance this feature to populate the arp-responder so that if tenant A and tenant B wants to be able to communicate on this shared and isolated network, ARP responder for the VM of tenant A will be populated with Mac address of VM of the Tenant B, and vice versa. [1] https://blueprints.launchpad.net/neutron/+spec/isolated-network On Fri, Jan 10, 2014 at 10:00 PM, Jay Pipes jaypi...@gmail.com wrote: On Fri, 2014-01-10 at 17:06 +, CARVER, PAUL wrote: If anyone is giving any thought to networks that are available to multiple tenants (controlled by a configurable list of tenants) but not visible to all tenants I’d like to hear about it. I’m especially thinking of scenarios where specific networks exist outside of OpenStack and have specific purposes and rules for who can deploy servers on them. We’d like to enable the use of OpenStack to deploy to these sorts of networks but we can’t do that with the current “shared or not shared” binary choice. Hi Paul :) Please see here: https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg07268.html for a similar discussion. best, -jay ___ 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 -- Stephen Gran Senior Systems Integrator - theguardian.com Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] [Neutron] How do we know a host is ready to have servers scheduled onto it?
On 12/12/13 17:19, Chris Friesen wrote: On 12/12/2013 11:02 AM, Clint Byrum wrote: So I'm asking, is there a standard way to determine whether or not a nova-compute is definitely ready to have things scheduled on it? This can be via an API, or even by observing something on the nova-compute host itself. I just need a definitive signal that the compute host is ready. Is it not sufficient that nova service-list shows the compute service as up? If not, then maybe we should call that a bug in nova... The nova-compute service does not, currently, know about the health of, say, the neutron openvswitch agent running on the same hardware, although that being in good shape is necessary to be able to start instances and have them be useful. This kind of cross-project state coordination doesn't exist right now, AFAIK. Cheers, -- Stephen Gran Senior Systems Integrator - theguardian.com Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Vote required for certificate as first-class citizen - SSL Termination (Revised)
Hi, Right, sorry, I see that wasn't clear - I blame lack of coffee :) I would prefer the Revised New Model. I much prefer the ability to restore a loadbalancer from config in the event of node failure, and the ability to do basic sharing of certificates between VIPs. I think that a longer term plan may involve putting the certificates in a smarter system if we decide we want to do things like evaluate trust models, but just storing them locally for now will do most of what I think people want to do with SSL termination. Cheers, On 05/12/13 09:57, Samuel Bercovici wrote: Hi Stephen, To make sure I understand, which model is fine Basic/Simple or New. Thanks, -Sam. -Original Message- From: Stephen Gran [mailto:stephen.g...@theguardian.com] Sent: Thursday, December 05, 2013 8:22 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Vote required for certificate as first-class citizen - SSL Termination (Revised) Hi, I would be happy with this model. Yes, longer term it might be nice to have an independent certificate store so that when you need to be able to validate ssl you can, but this is a good intermediate step. Cheers, On 02/12/13 09:16, Vijay Venkatachalam wrote: LBaaS enthusiasts: Your vote on the revised model for SSL Termination? Here is a comparison between the original and revised model for SSL Termination: *** Original Basic Model that was proposed in summit *** * Certificate parameters introduced as part of VIP resource. * This model is for basic config and there will be a model introduced in future for detailed use case. * Each certificate is created for one and only one VIP. * Certificate params not stored in DB and sent directly to loadbalancer. * In case of failures, there is no way to restart the operation from details stored in DB. *** Revised New Model *** * Certificate parameters will be part of an independent certificate resource. A first-class citizen handled by LBaaS plugin. * It is a forwarding looking model and aligns with AWS for uploading server certificates. * A certificate can be reused in many VIPs. * Certificate params stored in DB. * In case of failures, parameters stored in DB will be used to restore the system. A more detailed comparison can be viewed in the following link https://docs.google.com/document/d/1fFHbg3beRtmlyiryHiXlpWpRo1oWj8FqVe ZISh07iGs/edit?usp=sharing -- Stephen Gran Senior Systems Integrator - theguardian.com Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] Heat API v2 - Removal of template_url?
On 05/12/13 16:11, ELISHA, Moshe (Moshe) wrote: Hey, I really liked the v2 Heat API (as proposed in Create a new v2 Heat API https://blueprints.launchpad.net/heat/+spec/v2api) and I think it makes a lot of sense. One of the proposed changes is to “Remove template_url from the request POST”, so the template will be passed using the “template” parameter in the request body. Could someone please elaborate how exactly Heat Orchestration Templates written in YAML will be embedded in the body? As I understand the YAML template should be inserted as string otherwise JSON parsers will not be able to parse the JSON body. If indeed the template is inserted as string, as far as I know, JSON does not support multiline strings and the available workarounds are not so pretty and require escaping. The escaping issue gets more complicated when UserData is used in the YAML. Will the “template_url” be removed and if so how will the “template” contain the YAML template? Oh, that would be sad indeed. We're just looking at this pattern in AWS: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-stack.html And using that in heat as well would be very welcome. Cheers, -- Stephen Gran Senior Systems Integrator - theguardian.com Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Vote required for certificate as first-class citizen - SSL Termination (Revised)
Hi, I would be happy with this model. Yes, longer term it might be nice to have an independent certificate store so that when you need to be able to validate ssl you can, but this is a good intermediate step. Cheers, On 02/12/13 09:16, Vijay Venkatachalam wrote: LBaaS enthusiasts: Your vote on the revised model for SSL Termination? Here is a comparison between the original and revised model for SSL Termination: *** Original Basic Model that was proposed in summit *** * Certificate parameters introduced as part of VIP resource. * This model is for basic config and there will be a model introduced in future for detailed use case. * Each certificate is created for one and only one VIP. * Certificate params not stored in DB and sent directly to loadbalancer. * In case of failures, there is no way to restart the operation from details stored in DB. *** Revised New Model *** * Certificate parameters will be part of an independent certificate resource. A first-class citizen handled by LBaaS plugin. * It is a forwarding looking model and aligns with AWS for uploading server certificates. * A certificate can be reused in many VIPs. * Certificate params stored in DB. * In case of failures, parameters stored in DB will be used to restore the system. A more detailed comparison can be viewed in the following link https://docs.google.com/document/d/1fFHbg3beRtmlyiryHiXlpWpRo1oWj8FqVeZISh07iGs/edit?usp=sharing -- Stephen Gran Senior Systems Integrator - theguardian.com Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] DHCP Agent Reliability
On 03/12/13 16:08, Maru Newby wrote: I've been investigating a bug that is preventing VM's from receiving IP addresses when a Neutron service is under high load: https://bugs.launchpad.net/neutron/+bug/1192381 High load causes the DHCP agent's status updates to be delayed, causing the Neutron service to assume that the agent is down. This results in the Neutron service not sending notifications of port addition to the DHCP agent. At present, the notifications are simply dropped. A simple fix is to send notifications regardless of agent status. Does anybody have any objections to this stop-gap approach? I'm not clear on the implications of sending notifications to agents that are down, but I'm hoping for a simple fix that can be backported to both havana and grizzly (yes, this bug has been with us that long). Fixing this problem for real, though, will likely be more involved. The proposal to replace the current wsgi framework with Pecan may increase the Neutron service's scalability, but should we continue to use a 'fire and forget' approach to notification? Being able to track the success or failure of a given action outside of the logs would seem pretty important, and allow for more effective coordination with Nova than is currently possible. It strikes me that we ask an awful lot of a single neutron-server instance - it has to take state updates from all the agents, it has to do scheduling, it has to respond to API requests, and it has to communicate about actual changes with the agents. Maybe breaking some of these out the way nova has a scheduler and a conductor and so on might be a good model (I know there are things people are unhappy about with nova-scheduler, but imagine how much worse it would be if it was built into the API). Doing all of those tasks, and doing it largely single threaded, is just asking for overload. Cheers, -- Stephen Gran Senior Systems Integrator - theguardian.com Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up
On 19/11/13 16:33, Clint Byrum wrote: Excerpts from Vijay Venkatachalam's message of 2013-11-19 05:48:43 -0800: Hi Sam, Eugene, Avishay, etal, Today I spent some time to create a write-up for SSL Termination not exactly design doc. Please share your comments! https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2nYTvMkMJ_inbo/edit Would like comments/discussion especially on the following note: SSL Termination requires certificate management. The ideal way is to handle this via an independent IAM service. This would take time to implement so the thought was to add the certificate details in VIP resource and send them directly to device. Basically don't store the certificate key in the DB there by avoiding security concerns of maintaining certificates in controller. I don't see why it does. Nothing in openstack needs to trust user-uploaded certs. Just storing them as independent certificate objects that can be referenced by N VIPs makes sense to me. If the backend is SSL, I would think you could do one of: a) upload client certs b) upload CA that has signed backend certs c) opt to disable cert checking for backends With the default being c). Cheers, -- Stephen Gran Senior Systems Integrator - theguardian.com Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up
Hi, Yes, definitely yes. It's just a bootstrap problem - you can't both have a reliable, resilient loadbalancer that can be respawned, and not store all the data necessary to respawn it. I agree there are privacy concerns, just as there are with any hoster. But if you don't trust your hoster with your SSL certs, you probably shouldn't host any content that matters with them. Cheers, On Wed, 2013-11-20 at 08:43 +, Samuel Bercovici wrote: Hi Stephen, When this was discussed in the past, customer were not happy about storing their SSL certificates in the OpenStack database as plain fields as they felt that this is not secured enough. Do you say, that you are OK with storing SSL certificates in the OpenStack database? -Sam. -Original Message- From: Stephen Gran [mailto:stephen.g...@theguardian.com] Sent: Wednesday, November 20, 2013 10:15 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up On 19/11/13 16:33, Clint Byrum wrote: Excerpts from Vijay Venkatachalam's message of 2013-11-19 05:48:43 -0800: Hi Sam, Eugene, Avishay, etal, Today I spent some time to create a write-up for SSL Termination not exactly design doc. Please share your comments! https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2nYT vMkMJ_inbo/edit Would like comments/discussion especially on the following note: SSL Termination requires certificate management. The ideal way is to handle this via an independent IAM service. This would take time to implement so the thought was to add the certificate details in VIP resource and send them directly to device. Basically don't store the certificate key in the DB there by avoiding security concerns of maintaining certificates in controller. I don't see why it does. Nothing in openstack needs to trust user-uploaded certs. Just storing them as independent certificate objects that can be referenced by N VIPs makes sense to me. If the backend is SSL, I would think you could do one of: a) upload client certs b) upload CA that has signed backend certs c) opt to disable cert checking for backends With the default being c). Cheers, -- Stephen Gran Senior Systems Integrator - theguardian.com Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ 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 -- Stephen Gran Senior Systems Integrator - The Guardian Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place
Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up
Hi, On Wed, 2013-11-20 at 08:24 +, Samuel Bercovici wrote: Hi, Evgeny has outlined the wiki for the proposed change at: https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL which is in line with what was discussed during the summit. The https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2nYTvMkMJ_inbo/edit discuss in addition Certificate Chains. What would be the benefit of having a certificate that must be connected to VIP vs. embedding it in the VIP? You could reuse the same certificate for multiple loadbalancer VIPs. This is a fairly common pattern - we have a dev wildcard cert that is self-signed, and is used for lots of VIPs. When we get a system that can store certificates (ex: Barbican), we will add support to it in the LBaaS model. It probably doesn't need anything that complicated, does it? Cheers, -- Stephen Gran Senior Systems Integrator - The Guardian Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Loadbalancer instance design.
On 15/11/13 13:14, Eugene Nikanorov wrote: Hi folks, I've created a brief description of this feature. You can find it here: https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance https://blueprints.launchpad.net/neutron/+spec/lbaas-service-instance I would appreciate any comments/ideas about this. This is great - we're starting to experiment with running an appliance load balancer as an openstack instance. The only quirk so far is that we need to add new vips to the allowed_addresses list on the neutron port, and the API for doing so doesn't allow for incremental updates, so is a bit racy. Cheers, -- Stephen Gran Senior Systems Integrator - theguardian.com Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Continue discussing multi-region orchestration
On 15/11/13 18:35, Georgy Okrokvertskhov wrote: First of all, I believe this approach assumes that heat engine can reach API endpoints which are located in different region. I am not sure if it is a default deployment approach when someone is exposing OpenStack services endpoints to the outside of the local DC network. The same problem occurs with communication from VM to Heat engine. Heat passes IP address for cloud watch, ceilometer and for signaling in order to use waitcoinditions. So do you expect that VM will be able to communicate with Heat engine who is in different location? That will assume that networks in both locations are tightly coupled which is not the common case I believe. Surely those are local deployment policy decisions that shouldn't affect the development of capabilities in heat itself, right? If a deployer does not want one heat deployment to be able to reach some endpoints, they'll set up a local heat that can reach those endpoints and deploy their stack through that one, right? Cheers, -- Stephen Gran Senior Systems Integrator - theguardian.com Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] how can I know a new instance is created from the code ?
On 15/11/13 18:55, terryxing wrote: Hi Dear All, I am wondering that is there any way in Openstack to know when new instance is created ? is there any Python API to do this ? Since I want to monitor the instance creation event and trigger another event, thus, my program needs to be know whenever a new instance is created. I can run a daemon keep listening the nova-manage or other, when a new instance is created, this daemon will know then let other program know to take some actions. Nova can be configured to send notifications via MQ when actions occur. Please see https://ask.openstack.org/en/question/2224/novaquantum-notifications-in-rabbitmq/ for an example. Cheers, -- Stephen Gran Senior Systems Integrator - theguardian.com Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [scheduler] [heat] Policy specifics
On 27/09/13 07:58, Mike Spreitzer wrote: I have begun to draft some specifics about the sorts of policies that might be added to infrastructure to inform a smart unified placement engine. These are cast as an extension to Heat templates. See https://wiki.openstack.org/wiki/Heat/PolicyExtension. Comments solicited. Maybe I'm missing something obvious, but I'm not convinced all that logic belongs in Heat. I would expect nova and related components to expose grouping information (availability zones in nova, networks in quantum, etc) and for end users to supply the group by information. In other words, when I want to create a stack, I would tell Heat that I'd like this stack in all zones or a subset of zones, and if I expect a specific subset of zones, I should have to name them. I would not expect Heat to try to make smart placement decisions on my behalf. I think that your use case for anti-collocation (which is a very good and important use case, don't get me wrong) is covered by using availability zones/cells/regions and so on as they are, and doesn't require much logic internal to Heat beyond obeying the constraint specified by a user. Even LLMN Anti-Collocation can be reduced to nested stacks, where the inner stacks are anti-collocated across machines, the next level are anti-collocated across racks, and the top level across rooms (so long as the compute API exposes machines, racks and rooms to Heat - again, I don't think it's Heat's job to know about these). Cheers, -- Stephen Gran Senior Systems Integrator - theguardian.com Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [scheduler] [heat] Policy specifics
On 27/09/13 14:27, Mike Spreitzer wrote:
Stephen Gran stephen.g...@theguardian.com wrote on 09/27/2013 04:26:37 AM:
I think that your use case for anti-collocation (which is a very good
and important use case, don't get me wrong) is covered by using
availability zones/cells/regions and so on as they are, and doesn't
require much logic internal to Heat beyond obeying the constraint
specified by a user.
If there are five racks in the system and I want to say that two VMs
should be placed on different racks, how do I say that with AZs without
being overly specific?
If the admins of the openstack install wanted users to be able to select
placement by rack, surely the availability zones would be rack1 - rack5
? In this case, the user would write:
Resources : {
MyASG : {
Type : AWS::AutoScaling::AutoScalingGroup,
Properties : {
AvailabilityZones : { Fn::GetAZs : },
MinSize : 2,
DesiredSize: 2,
MaxSize : 2,
}
},
This should naturally implement placement as spread evenly across AZs.
I think maybe this is where I think my disagreement is. Heat should be
able to express a user preference for placement, but only within the
bounds of the policy already created by the admins of the nova install.
To have Heat have more knowledge than what is available via the nova
API seems overcomplicated and fragile to me. If the nova API should
grow some extensions to make more complicated placement algorithms
available, then that's an argument that might have legs.
Cheers,
--
Stephen Gran
Senior Systems Integrator - theguardian.com
Please consider the environment before printing this email.
--
Visit theguardian.com
On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad
Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access.
Visit subscribe.theguardian.com
This e-mail and all attachments are confidential and may also
be privileged. If you are not the named recipient, please notify
the sender and delete the e-mail and all attachments immediately.
Do not disclose the contents to another person. You may not use
the information for any purpose, or store, or copy, it in any way.
Guardian News Media Limited is not liable for any computer
viruses or other material transmitted with or as part of this
e-mail. You should employ virus checking software.
Guardian News Media Limited
A member of Guardian Media Group plc
Registered Office
PO Box 68164
Kings Place
90 York Way
London
N1P 2AP
Registered in England Number 908396
--
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] VIP for LBaaS on same port?
Hi, One of the things I'll be looking at in the near future is writing a driver for the neutron lbaas service to talk to a bit of hardware we have. The normal idiom with this hardware is to have a single interface, with multiple IP addresses attached. It doesn't look like this is currently possible in the lbaas model - loadbalancer_db.py unconditionally creates a port. What I am hoping to be able to do is create instances within openstack based on appliance images, give them a neutron port on the right subnet, and then add secondary IPs as people create loadbalancers. This would also give us the flexibility to attach security groups to that single port more easily, but that's a nice side effect. Does this sound possible? What would be the best way of achieving this, given the way things work currently? Cheers, -- Stephen Gran Senior Systems Integrator - theguardian.com Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 32% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] VIP for LBaaS on same port?
On 05/09/13 08:27, Itsuro ODA wrote: Hi, Please consider the following use case make abailable too: ip address/subnet of vips are same but protocol_port are diffrent. This is not able either currently. Oh yes, I'll certainly need that ability as well. Well, one more thing to put on the list to look at :) Cheers, -- Stephen Gran Senior Systems Integrator - theguardian.com Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 32% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Why is network and subnet modeled separately?
Hi, On 14/08/13 21:12, Lorin Hochstein wrote: Here's a neutron implementation question: why does neutron model network and subnet as separate entities? Or, to ask another way, are there are any practical use cases where you would *not* have a one-to-one relationship between neutron networks and neutron subnets in an OpenStack deployment? (e.g. one neutron network associated with multiple neutron subnets, or one neutron network associated with zero neutron subnets)? Different tenants might both use the same subnet range on different layer 2 networks. One one layer 2 network, you might run dual stacked, ie, ipv4 and ipv6. Supporting these use cases necessitates modeling them separately. Cheers, -- Stephen Gran Senior Systems Integrator - theguardian.com Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 32% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] FWaaS: Support for explicit commit
On 03/08/13 02:43, Sumit Naiksatam wrote: Hi All, In Neutron Firewall as a Service (FWaaS), we currently support an implicit commit mode, wherein a change made to a firewall_rule is propagated immediately to all the firewalls that use this rule (via the firewall_policy association), and the rule gets applied in the backend firewalls. This might be acceptable, however this is different from the explicit commit semantics which most firewalls support. Having an explicit commit operation ensures that multiple rules can be applied atomically, as opposed to in the implicit case where each rule is applied atomically and thus opens up the possibility of security holes between two successive rule applications. This all seems quite reasonable. So the proposal here is quite simple - * When any changes are made to the firewall_rules (added/deleted/updated), no changes will happen on the firewall (only the corresponding firewall_rule resources are modified). I would leave the default as it currently is, and make this an optional mode that can be triggered with a parameter. This seems to me to preserve the principal of least surprise for everyday operations, but allow for more complicated things when needed. * We will support an explicit commit operation on the firewall resource. Any changes made to the rules since the last commit will now be applied to the firewall when this commit operation is invoked. * A show operation on the firewall will show a list of the currently committed rules, and also the pending changes. Kindly respond if you have any comments on this. Cheers, -- Stephen Gran Senior Systems Integrator - theguardian.com Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 32% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] sqlite doesn't support migrations
On 15/07/13 09:26, Thomas Goirand wrote: Dolph, If you do that, then you will be breaking Debian packages, as they expect Sqlite as the default, for example when using DEBIAN_FRONTEND=noninteractive apt-get install keystone (if you choose MySQL, then you need to enter admin credentials to setup the db). I will receive tons of piupart failures reports if we can't upgrade with SQLite. I would really be disappointed if this happens, and get into situations where I have RC bugs which I can't realistically close by myself. So really, if it is possible, continue to support it, at least from one release to the next. Why not just change the default for Debian? Sqlite isn't particularly useful for actual deployments anyway. Cheers, -- Stephen Gran Senior Systems Integrator - guardian.co.uk Please consider the environment before printing this email. -- Visit guardian.co.uk - website of the year www.guardian.co.ukwww.observer.co.uk www.guardiannews.com www.guardian.co.uk/australia On your mobile, visit m.guardian.co.uk or download the Guardian iPhone app www.guardian.co.uk/iphone and iPad edition www.guardian.co.uk/iPad Save up to 32% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.guardian.co.uk - This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
