> Look, I'm talking a lot and not showing up with code, so I'm squelching myself.
Noted, and ditto. Thanks for the dialog. Doug On 6/16/14, 5:54 PM, "Clint Byrum" <[email protected]> wrote: >Excerpts from Doug Wiegley's message of 2014-06-16 16:10:51 -0700: >> Hi Clint, >> >> Comments below. >> >> On 6/16/14, 3:06 PM, "Clint Byrum" <[email protected]> wrote: >> >> >Excerpts from Doug Wiegley's message of 2014-06-16 13:22:26 -0700: >> >> > nobody is calling Barbican "a database". It is a place to store >> >> >> >> Š did you at least feel a heavy sense of irony as you typed those two >> >> statements? ³It¹s not a database, it just stores things!² :-) >> >> >> > >> >Not at all, though I understand that, clipped as so, it may look a bit >> >ironic. >> > >> >I was using shorthand of "database" to mean a general purpose >>database. I >> >should have qualified it to avoid any confusion. It is a narrow purpose >> >storage service with strong access controls. We can call that a >>database >> >if you like, but I think it has one very tiny role, and that is to >>audit >> >and control access to secrets. >> > >> >> The real irony here is that in this rather firm stand of keeping the >> >>user >> >> in control of their secrets, you are actually making the user LESS in >> >> control of their secrets. Copies of secrets will have to be made, >> >>whether >> >> stored under another tenant, or shadow copied somewhere. And the >>user >> >> will have no way to delete them, or even know that they exist. >> >> >> > >> >Why would you need to make copies outside of the in-RAM copy that is >> >kept while the service runs? You're trying to do too much instead of >> >operating in a nice loosely coupled fashion. >> >> I’ll come back to this. >> >> > >> >> The force flag would eliminate the common mistake cases enough that >>I¹d >> >> wager lbaas and most others would cease to worry, not duplicate, and >> >>just >> >> reference barbican id¹s and nothing else. (Not including backends >>that >> >> will already make a copy of the secret, but things like servicevm >>will >> >>not >> >> need to dup it.) The earlier assertion that we have to deal with the >> >> missing secrets case even with a force flag is, I think, false, >>because >> >> once the common errors have been eliminated, the potential window of >> >> accidental pain is reduced to those that really ask for it. >> > >> >The accidental pain thing makes no sense to me. I'm a user and I take >> >responsibility for my data. If I don't want to have that >>responsibility, >> >I will use less privileged users and delegate the higher amount of >> >privilege to a system that does manage those relationships for me. >> > >> >Do we have mandatory file locking in Unix? No we don't. Why? Because >>some >> >users want the power to remove files _no matter what_. We build in the >> >expectation that things may disappear no matter what you do to prevent >> >it. I think your LBaaS should be written with the same assumption. It >> >will be more resilient and useful to more people if they do not have to >> >play complicated games to remove a secret. >> >> There is literally no amount of resilience that can recover an HTTPS >> service that has no SSL private key. It’s just down. Worse, it’s not >> down when the user takes the action; it’s down at some indeterminate >>point >> in the future (e.g. when it reboots next, or when the LB has to move >>two a >> different servicevm.) We could sub in a self-signed cert in that case, >> though that’s as bad as down in many contexts. >> > >This is way too much focus on problems that are not LBaaS's. Help users >make keys for all other services, both inside the cloud and in the >user's machines, more reliable.. don't just magically make them reliable >for LBaaS. > >> I could be pedantic and point out that NFS files in use can’t be >>deleted, >> but that’s not relevant to your point. :-) >> > >On the remote system, correct. On the home system, they can be rm'd >right out from under the nfsd and there's nothing it can do about it. > >And that's just my point. NFS is a distributed system, and thus will >try to take care of the distributed system, but the lower level thing, >the host, is unencumbered by the service. > >I'm suggesting that LBaaS and Barbican are both low level services, >and thus should not be doing anything at a higher level. > >> > >> >Anyway, nobody has answered this. What user would indiscriminately >>delete >> >their own data and expect that things depending on that data will >>continue >> >to work indefinitely? >> >> Maybe there are multiple admins and a miscommunication? Memory lapse? >> What kind of customer base do you have that doesn’t make those kinds of >> mistakes *all the time*? You’re assuming a perfect user with a perfect >> memory; accidents happen. Now pair that with a wildcard cert used by >>1000 >> sites, and you’ve just one-clicked your way into *an extremely bad day*. >> And you won’t even know it, until your pager starts to go off at some >> later date. >> > >This is the same reason we don't login to systems as root and just do >whatever, right? We make admins funnel changes through a structured system >that can be reviewed, tracked, and collaborated on. But we still have >root.. and we still need it for zomg wtf times when the tooling fails. > >How about you give users the rights to create keys and load balancers, >but not to delete? Make them gain higher privileges to delete, but use >that same privilege escalation automatically when you're using automation. >I understand this is similar to the force flag, but it is also an optional >thing that users won't be forced to use. > >This maintains the simple distributed nature, gives users a "safe" way >to use if they want, but doesn't force all users to work in the way you >expect them to and doesn't add a lot of extra plumbing to the system. > >> Neutron doesn’t let you delete objects in use, e.g. Lots of other >> examples in the API. I’m not saying don’t let them cut their own foot >> off, if that’s their choice (the unix delete example.) But don’t make >>it >> easy, just because “they’d all just use force all the time anyway.” >> > >Neutron owns all of those objects. They're all inside Neutron because >their physical counterparts are literally tightly coupled with copper >and fiber. That is not actually desired, it is a constraint of the >system. > >> >Why would you need to make copies outside of the in-RAM copy that is >> >kept while the service runs? You're trying to do too much instead of >> >operating in a nice loosely coupled fashion. >> >> Back to this — what you describe is what we *want* to do, but you have a >> pile of operators and admins that aren’t comfortable with having a >>single >> click, somewhere not related to the service, quietly setting a time bomb >> for a later service failure/downtime. Giving the user a way to easily >> discover how much of their foot they’re about to blow off, before doing >> it, is what we’re asking for. And without it, I expect that workarounds >> of all varieties will proliferate up and down the stack. > >That's a noble goal, but not one for low level services to advance. You >have described the main use case for orchestration: Tie together services >and machines in a way that is understandable and entirely under the >control of users. > >> >> Force flag, soft deletes, resource tracking, even just displaying who’s >> using what for a visual cue; there are any number of ways to make this >> less dangerous without pushing it onto every consumer of your service. >> > >They're also ways to make the system more complex and brittle. > >Look, I'm talking a lot and not showing up with code, so I'm squelching >myself. The point is that this is a distributed system, and should be >built one service at a time. Services that do too much are going to be >overly complex. I am happy to assist anybody in becoming a Heat user >who agrees with me and thinks that something like Heat should be the >way users safely consume cross-project relationships. > >_______________________________________________ >OpenStack-dev mailing list >[email protected] >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
