Re: [openstack-dev] Unified Guest Agent proposal
Excerpts from Joshua Harlow's message of 2013-12-06 23:53:47 -0800: > Agreed, > > Chatting earlier today on #cloud-init about all of this I think scott > convinced me that maybe we (the joint we in the community at large) should > think about asking ourselves what do we really want a guest agent for/to do? > > If it's for software installation or user management then aren't puppet, > chef, juju (lots of others) good enough? > Right those are system management agents. > If it's for tracking what a vm is doing, aren't there many existing tools for > this already (sounds like monitoring to me). > Right general purpose system monitoring is a solved problem. > Is there a good list of what people really want out of a guest agent > (something unique that only a guest agent can do/is best at). If there is one > and it was already posted, my fault (I am on my iPhone which is not best for > emails...) > So what is needed is domain specific command execution and segregation of capabilities. With a general purpose config tool like chef or puppet, doing MySQL backups or adding MySQL users isn't really what they do. One might say that this is more like what fabric or mcollective do. That is definitely closer to what is desired. However there is still a different desire that may not fit well with those tools. Those tools are meant to give administrators rights to things on the box. But what Trove wants is to give the trove agent the ability to add a given MySQL user, but not the ability to, for instance, read the records and pass them back to the trove service. Likewise, Hadoop needs to run hadoop jobs, but not have full SSH to the machine. While the _nova_ admin with root on compute nodes may have the ability to just peek in on VMs, there is value in keeping the Trove/Savanna/Heat admins segregated from that. So basically there is a need for structure that general purpose tools may not have. I admit though, it seems like that would be something other tools outside of OpenStack would want as well. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Unified Guest Agent proposal
On 7 December 2013 21:08, Clint Byrum wrote: > So what is needed is domain specific command execution and segregation > of capabilities. Sounds rather like mcollective. -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ 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 Fri, Dec 06, 2013 at 04:30:17PM +0900, Maru Newby wrote: > >> 2. A 'best-effort' refactor that maximizes the reliability of the DHCP > >> agent. > >> > >> I'm hoping that coming up with a solution to #1 will allow us the > >> breathing room to work on #2 in this cycle. > > > > Loss of notifications is somewhat inevitable, I think. > > (Or logging tasks to stable storage shared between server and agent) > > And Unconditionally sending notifications would cause problem. > > Regarding sending notifications unconditionally, what specifically are you > worried about? I can imagine 2 scenarios: > > Case 1: Send notification to an agent that is incorrectly reported as down. > Result: Agent receives notification and acts on it. > > Case 2: Send notification to an agent that is actually down. > Result: Agent comes up eventually (in a production environment this should be > a given) and calls sync_state(). We definitely need to make sync_state more > reliable, though (I discuss the specifics later in this message). > > Notifications could of course be dropped if AMQP queues are not persistent > and are lost, but I don't think there needs to be a code-based remedy for > this. An operator is likely to deploy the AMQP service in HA to prevent the > queues from being lost, and know to restart everything in the event of > catastrophic failure. Case 3: Hardware failure. So an agent on the node is gone. Another agent will run on another node. If AMQP service is set up not to lose notification, notifications will be piled up and stress AMQP service. I would say single node failure isn't catastrophic. > That's not to say we don't have work to do, though. An agent is responsible > for communicating resource state changes to the service, but the service > neither detects nor reacts when the state of a resource is scheduled to > change and fails to do so in a reasonable timeframe. Thus, as in the bug > that prompted this discussion, it is up to the user to detect the failure (a > VM without connectivity). Ideally, Neutron should be tracking resource state > changes with sufficient detail and reviewing them periodically to allow > timely failure detection and remediation. You are proposing polling by Neutron server. So polling somewhere (in server or agent or hybrid) is the way to go in long term. Do you agree? Details to discuss would be, how to do polling, how often(or adaptive) polling should be done, how the cost of polling can be mitigated by tricks... > However, such a change is unlikely to be a candidate for backport so it will > have to wait. Right, this isn't for backport. I'm talking about middle/long term direction. > > You mentioned agent crash. Server crash should also be taken care of > > for reliability. Admin also sometimes wants to restart neutron > > server/agents for some reasons. > > Agent can crash after receiving notifications before start processing > > actual tasks. Server can crash after commiting changes to DB before sending > > notifications. In such cases, notification will be lost. > > Polling to resync would be necessary somewhere. > > Agreed, we need to consider the cases of both agent and service failure. > > In the case of service failure, thanks to recently merged patches, the dhcp > agent will at least force a resync in the event of an error in communicating > with the server. However, there is no guarantee that the agent will > communicate with the server during the downtime. While polling is one > possible solution, might it be preferable for the service to simply notify > the agents when it starts? The dhcp agent can already receive an > agent_updated RPC message that triggers a resync. Agreed, notification on server startup is better. > > - notification loss isn't considered. > > self.resync is not always run. > > some optimization is possible, for example > > - detect loss by sequence number > > - polling can be postponed when notifications come without loss. > > Notification loss due to agent failure is already solved - sync_state() is > called on startup. Notification loss due to server failure could be handled > as described above. I think the larger problem is that calling sync_state() > does not affect processing of notifications already in the queue, which could > result in stale notifications being processed out-of-order, e.g. > > - service sends 'network down' notification > - service goes down after committing 'network up' to db, but before sending > notification > - service comes back up > - agent knows (somehow) to resync, setting the network 'up' > - agent processes stale 'network down' notification > > Though tracking sequence numbers is one possible fix, what do you think of > instead ignoring all notifications generated before a timestamp set at the > beginning of sync_state()? I agree that improvement is necessary in the are and it is better for agent to ignore stale notification s
[openstack-dev] [havana-stable] FFE request https://review.openstack.org/60651
Hi, We discovered a very serious issue whilst running the CI. The Vmwareminesweeper would fail due to being unable to schedule instances. The root cause was incorrect except handling. Would it be possible to please get this into the stable havana release. Thanks Gary ___ 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 7 December 2013 21:53, Isaku Yamahata wrote: > > Case 3: Hardware failure. So an agent on the node is gone. > Another agent will run on another node. > > If AMQP service is set up not to lose notification, notifications will be > piled up > and stress AMQP service. I would say single node failure isn't catastrophic. So we should have AMQP set to discard notifications if there is noone listening: when an agent connects after an outage, it first starts listening, then does a poll for updates it missed. -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Unified Guest Agent proposal
On Sat, Dec 7, 2013 at 9:08 AM, Clint Byrum wrote: > So what is needed is domain specific command execution and segregation > of capabilities. > To further this, I know that a lot of security minded people consider this types of agent sorts of backdoors. Having one generic "backdoor" that can do everything is something that could be less acceptable as you would not have the choice to pinpoint what you'd like to allow it to do, or then the constraints in terms of fine grained access control becomes huge. I did not realize this until I too spoke with Scott about this. Cloud-init, or any such generic tool, should only enable deployment domain specific tool, based on the specific needs of given use case, not become an agent (backdoor) itself. This said, I imagine we could get some benefits out of a generic framework/library that could be used create such agents in a manner where base authentication and access control is done properly. This would allow to simplify security analysis and impacts of agents developped using that framework, but the framework itself should never become a generic binary that is deploy everywhere by default and allow way too much in itself. Binary instances of agents written using the framework would be what could be eventually deployed via cloud-init on a case by case basis. Wdyt? Nick -- Nicolas Barcet a.k.a. nijaba, nick ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] [glance] Heater Proposal
On 12/06/2013 08:55 PM, Clint Byrum wrote: Excerpts from Jay Pipes's message of 2013-12-06 16:46:24 -0800: On 12/06/2013 01:38 PM, Clint Byrum wrote: Excerpts from Jay Pipes's message of 2013-12-05 21:32:54 -0800: On 12/05/2013 04:25 PM, Clint Byrum wrote: Excerpts from Andrew Plunk's message of 2013-12-05 12:42:49 -0800: Excerpts from Randall Burt's message of 2013-12-05 09:05:44 -0800: On Dec 5, 2013, at 10:10 AM, Clint Byrum wrote: Excerpts from Monty Taylor's message of 2013-12-04 17:54:45 -0800: Why not just use glance? I've asked that question a few times, and I think I can collate the responses I've received below. I think enhancing glance to do these things is on the table: 1. Glance is for big blobs of data not tiny templates. 2. Versioning of a single resource is desired. 3. Tagging/classifying/listing/sorting 4. Glance is designed to expose the uploaded blobs to nova, not users My responses: 1: Irrelevant. Smaller things will fit in it just fine. Fitting is one thing, optimizations around particular assumptions about the size of data and the frequency of reads/writes might be an issue, but I admit to ignorance about those details in Glance. Optimizations can be improved for various use cases. The design, however, has no assumptions that I know about that would invalidate storing blobs of yaml/json vs. blobs of kernel/qcow2/raw image. I think we are getting out into the weeds a little bit here. It is important to think about these apis in terms of what they actually do, before the decision of combining them or not can be made. I think of HeatR as a template storage service, it provides extra data and operations on templates. HeatR should not care about how those templates are stored. Glance is an image storage service, it provides extra data and operations on images (not blobs), and it happens to use swift as a backend. If HeatR and Glance were combined, it would result in taking two very different types of data (template metadata vs image metadata) and mashing them into one service. How would adding the complexity of HeatR benefit Glance, when they are dealing with conceptually two very different types of data? For instance, should a template ever care about the field "minRam" that is stored with an image? Combining them adds a huge development complexity with a very small operations payoff, and so Openstack is already so operationally complex that HeatR as a separate service would be knowledgeable. Only clients of Heat will ever care about data and operations on templates, so I move that HeatR becomes it's own service, or becomes part of Heat. I spoke at length via G+ with Randall and Tim about this earlier today. I think I understand the impetus for all of this a little better now. Basically what I'm suggesting is that Glance is only narrow in scope because that was the only object that OpenStack needed a catalog for before now. However, the overlap between a catalog of images and a catalog of templates is quite comprehensive. The individual fields that matter to images are different than the ones that matter to templates, but that is a really minor detail isn't it? I would suggest that Glance be slightly expanded in scope to be an object catalog. Each object type can have its own set of fields that matter to it. This doesn't have to be a minor change to glance to still have many advantages over writing something from scratch and asking people to deploy another service that is 99% the same as Glance. My suggestion for long-term architecture would be to use Murano for catalog/metadata information (for images/templates/whatever) and move the block-streaming drivers into Cinder, and get rid of the Glance project entirely. Murano would then become the catalog/registry of objects in the OpenStack world, Cinder would be the thing that manages and streams blocks of data or block devices, and Glance could go away. Imagine it... OpenStack actually *reducing* the number of projects instead of expanding! :) Have we not learned our lesson with Nova-Net/Neutron yet? Rewrites of existing functionality are painful. I said *long-term* above, Clint. The Murano-concerned people have already stated they are starting over on that catalog. I suggest they start over by expanding Glance's catalog. If the block streaming bits of Glance need to move somewhere else, that sounds like a completely separate concern that distracts from this point. Yes, the block streaming bits of Glance are separate -- sorry for distracting from your point. However, Glance's architecture actually went from having the registry and streaming pieces separated to having the two pieces more closely interwoven in the last two release cycles. It's harder now, IMO, to separate out the "registry" aspects of Glance from the block management pieces. Which is why I suggested using Murano as the catalog since there is already a separate catalog sub-project in Murano and the Murano devs are familiar with this
Re: [openstack-dev] stable/havana 2013.2.1 freeze tomorrow
2013/12/6 Alan Pevec : > 2013/12/4 Alan Pevec : >> first stable/havana release 2013.2.1 is scheduled[1] to be released >> next week on December 12th, so freeze on stable/havana goes into >> effect tomorrow EOD, one week before the release. > > We're behind with reviewing so we'll be doing soft-freeze today: > stable-maint members can review and approve currently open stable > reviews during Friday, but any new reviews coming in will be blocked. > Remaining open reviews will get temporary automatic -2 at EOD today > when call for testing will be posted. Just to give a quick status update: call for testing is delayed, bunch of approved changes were hit by tempest failures in gate jobs, I'm going to keep reverifying them until they get lucky and pass. Freeze is now in full effect, stable-maint members please don't approve any more changes unless they're freeze exception. The only requested freeze exceptions are "Sync rpc fix from oslo-incubator" for qpid v2 issues https://launchpad.net/bugs/1251757 and https://launchpad.net/bugs/1257293 If you have any other exception proposals, please raise them on stable-maint list. Cheers, Alan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Unified Guest Agent proposal
Excerpts from Robert Collins's message of 2013-12-07 00:17:19 -0800: > On 7 December 2013 21:08, Clint Byrum wrote: > > > So what is needed is domain specific command execution and segregation > > of capabilities. > > Sounds rather like mcollective. > It does actually. If it weren't explicitly tied to Ruby for its agent plugins I'd say it is a good drop-in candidate. There is actually an attempt to replace the ruby agent with C++ here: https://github.com/jedi4ever/mcollective-cpp-agents But it is 2+ years old so it is not clear at all if it was successful. Anyway, even if we can't use mcollective, I think we can copy its model, which is basically to have an AMQP (they use STOMP.. simpler than AMQP) broker sit between clients (Trove/Savanna/Heat) and agents. Then on the agents, you just have named plugins which can take inputs and produce outputs. So you'd put a 'mysql_db_crud' plugin on Trove managed instances, and a 'hadoop_run_job' plugin on Savanna instances. But the agent itself is basically the same everywhere. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Unified Guest Agent proposal
Excerpts from Nicolas Barcet's message of 2013-12-07 01:33:01 -0800: > On Sat, Dec 7, 2013 at 9:08 AM, Clint Byrum wrote: > > > So what is needed is domain specific command execution and segregation > > of capabilities. > > > > To further this, I know that a lot of security minded people consider this > types of agent sorts of backdoors. Having one generic "backdoor" that can > do everything is something that could be less acceptable as you would not > have the choice to pinpoint what you'd like to allow it to do, or then the > constraints in terms of fine grained access control becomes huge. I did > not realize this until I too spoke with Scott about this. Cloud-init, or > any such generic tool, should only enable deployment domain specific tool, > based on the specific needs of given use case, not become an agent > (backdoor) itself. > Right, we already have a backdoor agent on most OS's, it is called SSH and we are used to being _very_ careful about granting SSH access. > This said, I imagine we could get some benefits out of a generic > framework/library that could be used create such agents in a manner where > base authentication and access control is done properly. This would allow > to simplify security analysis and impacts of agents developped using that > framework, but the framework itself should never become a generic binary > that is deploy everywhere by default and allow way too much in itself. > Binary instances of agents written using the framework would be what could > be eventually deployed via cloud-init on a case by case basis. I think the mcollective model (see previous message about it) has undergone security review and is one to copy. It is mostly what you say. The agent is only capable of doing what its plugins can do, and it only needs to call out to a single broker, so poking holes for the agents to get out is fairly straight forward. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Unified Guest Agent proposal
On 12/07/2013 06:48 PM, Clint Byrum wrote: > Excerpts from Nicolas Barcet's message of 2013-12-07 01:33:01 -0800: >> On Sat, Dec 7, 2013 at 9:08 AM, Clint Byrum wrote: >> >>> So what is needed is domain specific command execution and segregation >>> of capabilities. >>> >> >> To further this, I know that a lot of security minded people consider this >> types of agent sorts of backdoors. Having one generic "backdoor" that can >> do everything is something that could be less acceptable as you would not >> have the choice to pinpoint what you'd like to allow it to do, or then the >> constraints in terms of fine grained access control becomes huge. I did >> not realize this until I too spoke with Scott about this. Cloud-init, or >> any such generic tool, should only enable deployment domain specific tool, >> based on the specific needs of given use case, not become an agent >> (backdoor) itself. >> > > Right, we already have a backdoor agent on most OS's, it is called SSH > and we are used to being _very_ careful about granting SSH access. > >> This said, I imagine we could get some benefits out of a generic >> framework/library that could be used create such agents in a manner where >> base authentication and access control is done properly. This would allow >> to simplify security analysis and impacts of agents developped using that >> framework, but the framework itself should never become a generic binary >> that is deploy everywhere by default and allow way too much in itself. >> Binary instances of agents written using the framework would be what could >> be eventually deployed via cloud-init on a case by case basis. > > I think the mcollective model (see previous message about it) has > undergone security review and is one to copy. It is mostly what you say. > The agent is only capable of doing what its plugins can do, and it only > needs to call out to a single broker, so poking holes for the agents to > get out is fairly straight forward. Sake of argument- salt's minion is very similar, and also has a plugin and acl model - and at least for us doesn't have the ruby issue. Of course, for _not_ us, it has the python issue. That said- it's designed to respond to zeromq messages, so writing a salt minion and plugins in c++ might not be hard to accomplish. short/medium term - why don't we just actually make use of salt minion for guest agents? It _is_ python based, which means sending it messages from trove or savana shouldn't be hard to integrate. It would be _fascinating_ to see if we could convince them to migrate from direct zeromq to using it through oslo.messaging. They're also pretty friendly. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Unified Guest Agent proposal
Sounds like a pretty neat idea. I like it! Another idea: instead of saying pushing for one agent to rule them all why don't we come up with a desired reference spec (maybe including a reference implementation?) that the salt, chef, mcollective, (other...) can base theres off of. In a way this creates a standard agent that can also be compatible with other agents (as long as said agents implement the same spec). Said spec could be based off a combination of the salt one and the rackspace one (...) but instead of "pushing" a single agent, openstack would "push" a spec instead. Sent from my really tiny device... > On Dec 7, 2013, at 11:17 AM, "Monty Taylor" wrote: > > > >> On 12/07/2013 06:48 PM, Clint Byrum wrote: >> Excerpts from Nicolas Barcet's message of 2013-12-07 01:33:01 -0800: On Sat, Dec 7, 2013 at 9:08 AM, Clint Byrum wrote: So what is needed is domain specific command execution and segregation of capabilities. >>> >>> To further this, I know that a lot of security minded people consider this >>> types of agent sorts of backdoors. Having one generic "backdoor" that can >>> do everything is something that could be less acceptable as you would not >>> have the choice to pinpoint what you'd like to allow it to do, or then the >>> constraints in terms of fine grained access control becomes huge. I did >>> not realize this until I too spoke with Scott about this. Cloud-init, or >>> any such generic tool, should only enable deployment domain specific tool, >>> based on the specific needs of given use case, not become an agent >>> (backdoor) itself. >> >> Right, we already have a backdoor agent on most OS's, it is called SSH >> and we are used to being _very_ careful about granting SSH access. >> >>> This said, I imagine we could get some benefits out of a generic >>> framework/library that could be used create such agents in a manner where >>> base authentication and access control is done properly. This would allow >>> to simplify security analysis and impacts of agents developped using that >>> framework, but the framework itself should never become a generic binary >>> that is deploy everywhere by default and allow way too much in itself. >>> Binary instances of agents written using the framework would be what could >>> be eventually deployed via cloud-init on a case by case basis. >> >> I think the mcollective model (see previous message about it) has >> undergone security review and is one to copy. It is mostly what you say. >> The agent is only capable of doing what its plugins can do, and it only >> needs to call out to a single broker, so poking holes for the agents to >> get out is fairly straight forward. > > Sake of argument- salt's minion is very similar, and also has a plugin > and acl model - and at least for us doesn't have the ruby issue. > > Of course, for _not_ us, it has the python issue. That said- it's > designed to respond to zeromq messages, so writing a salt minion and > plugins in c++ might not be hard to accomplish. > > short/medium term - why don't we just actually make use of salt minion > for guest agents? It _is_ python based, which means sending it messages > from trove or savana shouldn't be hard to integrate. It would be > _fascinating_ to see if we could convince them to migrate from direct > zeromq to using it through oslo.messaging. They're also pretty friendly. > > ___ > 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] [horizon] Purpose of SetDomainContext / UnsetDomainContext button
Greetings, I recently enabled multi-domain support on my dashboard and noticed a new domain context button. I was actually surprised to see I had to manually toggle the functionality to set the domain context, hiding domain foo resources from domain bar. My question is simple, what is the purpose of this functionality? For me, if I setup admins in 2 different domains, I don't want them to actually see the resources of the other, asking them to click said button seems to defeat the purpose. Right now, I am attempting to setup a configuration file settings that will force the domain_context to be setup on login, hence hiding external domain resources by default. But like I asked, trying to better understand the use case of the current functionality. -- Paul Belanger | PolyBeacon, Inc. Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode) Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Unified Guest Agent proposal
On 12/07/2013 11:09 PM, Joshua Harlow wrote: > Sounds like a pretty neat idea. > > I like it! > > Another idea: instead of saying pushing for one agent to rule them > all why don't we come up with a desired reference spec (maybe > including a reference implementation?) that the salt, chef, > mcollective, (other...) can base theres off of. In a way this creates > a standard agent that can also be compatible with other agents (as > long as said agents implement the same spec). Said spec could be > based off a combination of the salt one and the rackspace one (...) > but instead of "pushing" a single agent, openstack would "push" a > spec instead. I think that's overreaching and unlikely to be helpful longterm (although, in a perfect world...) Let me be clear about what I'm suggesting - on a topic such as this, I think it's very easy to quickly get confusing. The problem isn't that the world needs a unified guest agent - we'll NEVER get that to happen - it's that we need one for our services to use to do guest agent things. It's not important that our guest agent is the same at the guest agent systems that might be running at a given location. For instance, if someone uses puppet and mcollective at a site to deploy nova and trove, it's not important that the guest agent that trove uses to perform tasks in guests it spawns be the same as the orchestration system that the admins of that cloud use to perform config management tasks on their servers. So - it's not important that their personal deployment preferences be honored. I suggested salt because we could very easily make trove and savana into salt masters (if we wanted to) just by having them import salt library and run an api call. When they spin up nodes using heat, we could easily have that to the cert exchange - and the admins of the site need not know _anything_ about salt, puppet or chef - only about trove or savana. > Sent from my really tiny device... > >> On Dec 7, 2013, at 11:17 AM, "Monty Taylor" >> wrote: >> >> >> >>> On 12/07/2013 06:48 PM, Clint Byrum wrote: Excerpts from Nicolas >>> Barcet's message of 2013-12-07 01:33:01 -0800: > On Sat, Dec 7, 2013 at 9:08 AM, Clint Byrum > wrote: > > So what is needed is domain specific command execution and > segregation of capabilities. To further this, I know that a lot of security minded people consider this types of agent sorts of backdoors. Having one generic "backdoor" that can do everything is something that could be less acceptable as you would not have the choice to pinpoint what you'd like to allow it to do, or then the constraints in terms of fine grained access control becomes huge. I did not realize this until I too spoke with Scott about this. Cloud-init, or any such generic tool, should only enable deployment domain specific tool, based on the specific needs of given use case, not become an agent (backdoor) itself. >>> >>> Right, we already have a backdoor agent on most OS's, it is >>> called SSH and we are used to being _very_ careful about granting >>> SSH access. >>> This said, I imagine we could get some benefits out of a generic framework/library that could be used create such agents in a manner where base authentication and access control is done properly. This would allow to simplify security analysis and impacts of agents developped using that framework, but the framework itself should never become a generic binary that is deploy everywhere by default and allow way too much in itself. Binary instances of agents written using the framework would be what could be eventually deployed via cloud-init on a case by case basis. >>> >>> I think the mcollective model (see previous message about it) >>> has undergone security review and is one to copy. It is mostly >>> what you say. The agent is only capable of doing what its plugins >>> can do, and it only needs to call out to a single broker, so >>> poking holes for the agents to get out is fairly straight >>> forward. >> >> Sake of argument- salt's minion is very similar, and also has a >> plugin and acl model - and at least for us doesn't have the ruby >> issue. >> >> Of course, for _not_ us, it has the python issue. That said- it's >> designed to respond to zeromq messages, so writing a salt minion >> and plugins in c++ might not be hard to accomplish. >> >> short/medium term - why don't we just actually make use of salt >> minion for guest agents? It _is_ python based, which means sending >> it messages from trove or savana shouldn't be hard to integrate. It >> would be _fascinating_ to see if we could convince them to migrate >> from direct zeromq to using it through oslo.messaging. They're also >> pretty friendly. >> >> ___ OpenStack-dev >> mailing list OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman
Re: [openstack-dev] [horizon] Purpose of SetDomainContext / UnsetDomainContext button
The set domain context functionality is for operators (admins) to refine the context that they are working in/viewing. Admins can limit the scope of identity visibility to one domain, rather than having to sort through the exhaustive lists of projects, users, and groups. If you are adding multiple users with the admin role, they will still have visibility across domains. They will be able to see all instances, volumes, networks, etc. Currently, the domain scoping is only implemented for the identity management panel group. The intention is to extend the scoping to services beyond keystone as well. But even once that's implemented, any user with the admin role will be able to view/modify any instance, volume, network, etc., via the CLI. The functionality you are looking for is a way to view things as a domain admin. The domain admin role does not explicitly exist in OpenStack. It needs to, but does not. If implemented, a user with domain admin capabilities would not have the admin role and see entities in their domain much like what is seen in the current project dashboard. There are several Horizon blueprints in Icehouse to add RBAC support for the integrated services and consolidate the project and admin dashboards. Once those are implemented, then creating a domain admin role and modifying the policy.json files Horizon uses would allow the behavior you desire -- assuming you are using a policy.json file for keystone that also supports a domain admin role. This will look very much like the identity management panel group does today when the domain context is set. -David Lyle > -Original Message- > From: Paul Belanger [mailto:paul.belan...@polybeacon.com] > Sent: Saturday, December 07, 2013 7:49 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: [openstack-dev] [horizon] Purpose of SetDomainContext / > UnsetDomainContext button > > Greetings, > > I recently enabled multi-domain support on my dashboard and noticed a > new domain context button. I was actually surprised to see I had to > manually toggle the functionality to set the domain context, hiding > domain foo resources from domain bar. > > My question is simple, what is the purpose of this functionality? For > me, if I setup admins in 2 different domains, I don't want them to > actually see the resources of the other, asking them to click said > button seems to defeat the purpose. > > Right now, I am attempting to setup a configuration file settings that > will force the domain_context to be setup on login, hence hiding > external domain resources by default. > > But like I asked, trying to better understand the use case of the > current functionality. > > -- > Paul Belanger | PolyBeacon, Inc. > Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode) > Github: https://github.com/pabelanger | Twitter: > https://twitter.com/pabelanger > > ___ > 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] Unified Guest Agent proposal
On 8 December 2013 17:23, Monty Taylor wrote: > > I suggested salt because we could very easily make trove and savana into > salt masters (if we wanted to) just by having them import salt library > and run an api call. When they spin up nodes using heat, we could easily > have that to the cert exchange - and the admins of the site need not > know _anything_ about salt, puppet or chef - only about trove or savana. Are salt masters multi-master / HA safe? E.g. if I've deployed 5 savanna API servers to handle load, and they all do this 'just import', does that work? If not, and we have to have one special one, what happens when it fails / is redeployed? Can salt minions affect each other? Could one pretend to be a master, or snoop requests/responses to another minion? Is salt limited: is it possible to assert that we *cannot* run arbitrary code over salt? -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Unified Guest Agent proposal
On 12/08/2013 07:36 AM, Robert Collins wrote: > On 8 December 2013 17:23, Monty Taylor wrote: >> > >> I suggested salt because we could very easily make trove and savana into >> salt masters (if we wanted to) just by having them import salt library >> and run an api call. When they spin up nodes using heat, we could easily >> have that to the cert exchange - and the admins of the site need not >> know _anything_ about salt, puppet or chef - only about trove or savana. > > Are salt masters multi-master / HA safe? > > E.g. if I've deployed 5 savanna API servers to handle load, and they > all do this 'just import', does that work? > > If not, and we have to have one special one, what happens when it > fails / is redeployed? Yes. You can have multiple salt masters. > Can salt minions affect each other? Could one pretend to be a master, > or snoop requests/responses to another minion? Yes and no. By default no - and this is protected by key encryption and whatnot. They can affect each other if you choose to explicitly grant them the ability to. That is - you can give a minion an acl to allow it inject specific command requests back up into the master. We use this in the infra systems to let a jenkins slave send a signal to our salt system to trigger a puppet run. That's all that slave can do though - send the signal that the puppet run needs to happen. However - I don't think we'd really want to use that in this case, so I think they answer you're looking for is no. > Is salt limited: is it possible to assert that we *cannot* run > arbitrary code over salt? In as much as it is possible to assert that about any piece of software (bugs, of course, blah blah) But the messages that salt sends to a minion are "run this thing that you have a local definition for" rather than "here, have some python and run it" Monty ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
