Re: [Openstack] Summit considerations
Hi Marton, On Sun, Jan 29, 2017 at 07:51:33PM +, Marton Kiss wrote: > Hi Martin, > > You can find a short official answer to your question: > https://www.openstack.org/blog/2017/01/supporting-our-global-community/ > > Regards, > Marton Kiss > OpenStack Ambassador Thanks for the quick response and appropriate message. Best, Martin Millnert signature.asc Description: PGP signature ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack] Summit considerations
Dear fellow stackers, OpenStack summits should be open to all, regardless of religion. Effectively this currently means summits cannot be hosted within the US, per my understanding of current US policies. I wish the board can deliver a policy/statement addressing this. Best regards, fellow human, Martin Millnert PS. No partisan/political discussion required. Objective facts will do. DS signature.asc Description: PGP signature ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP
Hi Adrian, On Thu, 2016-09-08 at 12:58 +1200, Adrian Turjak wrote: > Double api sounds a little terrifying when really there are probably so > many different ways you can already solve this using the services we > already have. > > The thing I don't get is Martin's requirement that "an instance must > have internet on boot" Instances cannot be guaranteed to not require Internet... so it must be there from scratch, or things like for example Ubuntu's entropy download for ssh-generation in cloud-init will fail. > and that to do that he must have a floating ip > assigned to it. That's one of the networking models we have for public IP. > Internet on boot I can understand because of > preconfigured images and snapshots starting internal services and tasks > on boot, but why is floating ip on boot such a hard requirement? Is > adding a floating ip before boot even possible with Nova right now (I > ask as I've never looked into it)? >From what I understand, current calls for assigning floating IP requires not just the server, but a network port to exist. I assume "server create" finishes off with "server start". > Unless I'm missing something, you can easily setup a private network > with internet access, boot your instance on that, and then add a > floating ip. The instance will have internet on boot, and then be given > a floating ip. Does that not solve your problem and can that not be > orchestrated with the current range of services/tools we have? Our private networks are private networks, there is no Internet access from them without a floating IP, i.e. no source NAT. It's the VPC model. If our private networks were to, by default, not actually be private networks, and have source NAT to the Internet, then, yes, that'd solve that particular problem, at the expense of no longer having private networks. Best, Martin > On 08/09/16 12:41, Fox, Kevin M wrote: > > Interesting. It kind of sounds like your proposing a sort of... openstack > > standard library api api? (yes, double apis) Where you can build up an api > > using other api calls and users can rely on those standard overarching > > api's to be there? > > > > Thanks, > > Kevin > > > > From: Andrew Laski [and...@lascii.com] > > Sent: Wednesday, September 07, 2016 4:34 PM > > To: openstack-dev@lists.openstack.org > > Subject: Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance > > with Floating IP > > > > On Wed, Sep 7, 2016, at 06:54 PM, Martin Millnert wrote: > >> On Thu, 2016-09-08 at 09:34 +1200, Adrian Turjak wrote: > >>> This is exactly what something like Minstral would be fantastic for. > >>> Multi-project workflow. > >>> Rather than try and build logic like this directly into nova, looks > >>> at extending something like Minstral with a basic easy to call task. > >> I have API- and code-reading homework to do here - but based on input > >> on IRC, and efforts thus far, the ideal solution is not really to bolt > >> a humongous piece of logic onto Nova. Rather it is appears to be first > >> and foremost Neutron that need a little bit more intelligence regarding > >> its virtual networks and the intentions of its operators. > >> > >> From what I can tell, Mistral is a very useful project for scheduling > >> recurring tasks or similar, which there is a definite need of in a > >> mature deployment. > >> > >> But I disagree with the "solve it with a new project"-approach here: > >> > >> 1) "launch my instance" is as core as it gets in OpenStack, > >> > >> 2) "launch my instance with Internet" is approximately identically as > >> core, just a bit difficult for $reasons and not fully supported today, > >> > >> 3) core functionality should IMO require as few API calls as possible, > >> to as few components as possible, while keeping REST data models etc. > >> intact, [1][2] > > I agree that it should require as few API calls as possible but maybe we > > disagree about what core functionality is. Or to put it another way, > > what is core functionality depends on your perspective. > > > > I subscribe to the plumbing and porcelain approach > > (https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain) > > and believe that Nova should be part of the plumbing. So while I fully > > agree with a small number of API calls to do simple tasks I don't > > believe that orchestrating network setups is core functionality in Nova > > but is core to OpenStack. > > > >>
Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP
On Thu, 2016-09-08 at 09:34 +1200, Adrian Turjak wrote: > This is exactly what something like Minstral would be fantastic for. > Multi-project workflow. > Rather than try and build logic like this directly into nova, looks > at extending something like Minstral with a basic easy to call task. I have API- and code-reading homework to do here - but based on input on IRC, and efforts thus far, the ideal solution is not really to bolt a humongous piece of logic onto Nova. Rather it is appears to be first and foremost Neutron that need a little bit more intelligence regarding its virtual networks and the intentions of its operators. From what I can tell, Mistral is a very useful project for scheduling recurring tasks or similar, which there is a definite need of in a mature deployment. But I disagree with the "solve it with a new project"-approach here: 1) "launch my instance" is as core as it gets in OpenStack, 2) "launch my instance with Internet" is approximately identically as core, just a bit difficult for $reasons and not fully supported today, 3) core functionality should IMO require as few API calls as possible, to as few components as possible, while keeping REST data models etc. intact, [1][2] 4) there are timing concerns with adding Internet to an instance today in OpenStack, since it in some cases needs to happen somewhere between the events "network port created" and "instance launched", in order for the instance to actually have Internet when it boots, 5) Scheduling "Launch instance with Internet" or "Add Internet to instance" via something like Mistral would additionally either, A) add a significant delay to the boot time, or B) not even fulfill the objective of having Internet once instance powers on, 6) To replicate the logic of shade's "get me online" functions, a large amount of code is required, and depending on how you go about it, you also risk duplicating logic already in e.g. Nova or Neutron. Best regards, Martin [1] "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." -- Antoine de Saint-Exupery [2] https://tools.ietf.org/rfcdiff?url2=draft-heitz-idr-large-community -02.txt (example of commendable improvement almost unheard of within the IETF) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP
Hi Matt, On Tue, 2016-09-06 at 16:39 -0500, Matt Riedemann wrote: > Floating IPs aren't required in OpenStack deployments, and anyone > running with cells v1 (Rackspace, GoDaddy, NeCTAR, CERN) doesn't use > or > support them, at least without patching Nova. So I'm not sure what > 'industry standard' is being referred to here. Nod. There are many models, I acknowledge that as well. When referring to 'industry standard', I refer to e.g. default EC2 VPC or GCE non- legacy network behaviour. I didn't mean to imply that this model is the only one, not even the best one, just the most widely used one at large. > > Problem: > > - nova: we're not adding anything > > Correct, nova provides the APIs to do this already, something sitting > on top just needs to use them to orchestrate your use case. It exists in terms of multiple calls, yes. My e-mail is about what the best multi-project solution to improving the total logic required to achieve the goal, within OpenStack. It's not clear the answer is to improve Nova's server create API, but it is one very obvious candidate solution. > The get-me-a-network work is complete with the 2.37 API microversion > in Nova and the 6.0.0 python-novaclient release. You can test it out > today. > However, it does not allocate and auto-assign a floating IP. I'd argue that what a typical user is most interested in is not, in fact, in "having a network", but, "having internet access". Nova has the POST /servers 'fixed_ip' and 'networks' keys. Neither one of them, as you point out, deals with auto-allocating-and-assigning FIPs, which is fine in and of itself - Rome wasn't built in one day either. I.e. today, A) 'networks=auto' != "get me online", B) 'networks=auto' == "get me an openstack network interface". B is a subset of A, but A is not a subset of B. Assuming, 1) 'networks' is definitely meant to mean just what it's called, and does today, and 2) "get me online" is a desirable feature, then it is actually the case that we're missing an option like "public_ip=auto" or similar to complete the picture. In the deployments you mention above, it'd have virtually nothing to do. In others, for example FIP, it'd have only little to do. Then, the combination networks=auto, public_ip(v4)=auto would equal "getmeonline". > > So how can one solve an OpenStack cross-project problem like this, > > possibly without having to implement an artificial > > superintelligence > > first? > > Orchestrate on top of Nova's APIs, either in your own CLI, or UI, or > maybe even Heat would support this. Right, the total amount of options are thus: 1) Introduce a new, custom API service to proxy for Nova, and fork Horizon to handle it, 2) Patch Nova and do UI fixes in Horizon, but do not submit it upstream, 3) Patch Nova and do UI fixes in Horizon, and submit it upstream, 4) Make Horizon stateful and do UI changes, but do not submit it upstream, 5) Make Horizon stateful and do UI changes, and submit it upstream I'm sure there are more enumerations of this, but Heat is not one of them. :-) To me, from the above, option 3 seems the one that involves the least amount of complexity, which already there is a good indication of being the right choice. Best regards, Martin __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP
Hi, Goal: I'd like to replicate the industry standard of providing a on-by- default (UI) option to auto-assign a floating IP to a newly launched instance. It must be toggleable however (to follow industry standard). With openstackclient I'm hoping the feature could be added through e.g "--auto-assign-floating-ip", where it is unspecified where the stateful glue logic actually resides. Scenario: We use Horizon as UI and OpenContrail as VPC provider, where our virtual networks by default really are private networks, e.g. following actual industry standard VPC behaviour. Our users are today required to themselves perform the Assign Floating IP operation [1] operation before their instance has achieved what 98% of users desire. So this is both unexpected for users and likewise far from industry standard (defaults should make a happy user). Problem: Recognizing that deployments are different, and this probably won't satisfy 100% of deployments architecture, there is furthermore the unfortunate situation of: - nova: we're not adding anything - horizon: UI's not a brain I'm aware of the "--get-me-a-network" effort which is admirable. I haven't been on top of its progress, but from what I understand today it hasn't seen the light of day yet. Any update aligned with my goal would be helpful. So how can one solve an OpenStack cross-project problem like this, possibly without having to implement an artificial superintelligence first? For any operators around who've dealt with this, and possibly run a proprietary UI: Have you perchance added an ... "instance launch orchestrator" that takes arguments to this dear instance orchestration platform, seeing that Nova in fact *isn't* an "instance launch orchestrator" (at least not moddable)? We're at the point where we want this so much that we'll do it regardless of upstream, but I can't for the life of me think that we're alone with the use case. Regards, Martin Millnert [1] http://developer.openstack.org/api-ref/networking/v2/index.html?exp anded=create-floating-ip-detail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation
Hi Dolph, On Mon, 2016-04-18 at 17:50 -0500, Dolph Mathews wrote: > > On Mon, Apr 18, 2016 at 11:34 AM, Martin Millnert <mar...@millnert.se> > wrote: > Hi, > > we're deploying Liberty (soon Mitaka) with heavy reliance on > the SAML2 > Federation system by Keystone where we're a Service Provider > (SP). > > The problem in this situation is getting a token for direct > API > access.(*) > > There are conceptually two methods to use the CLI: > 1) Modify ones (each customer -- in our case O(100)) IdP to > add support > for a feature called ECP(**), and then use keystoneauth with > SAML2 > plugin, > 2) Go to (for example) "Access & Security / API Access / View > Credentials" in Horizon, and check out a token from there. > > > With a default configuration, this token would only last a short > period of time, so this would be incredibly repetitive (and thus > tedious). Indeed. > So, I assume you mean some sort of long-lived API tokens? Right. > API tokens, including keystone's UUID, PKI, PKIZ, and Fernet tokens > are all bearer tokens, so we force a short lifetime by default, > because there are always multiple parties capable of compromising the > integrity of a token. OAuth would be a counter example, where OAuth > access tokens can (theoretically) live forever. This does sound very interesting. As long as the end user gets something useful to plug into the openstack auth libraries/APIs, we're home free (modulo security considerations, etc). > 2) isn't implemented. 1) is a complete blocker for many > customers. > > Are there any principal and fundamental reasons why 2 is not > doable? > What I imagine needs to happen: > A) User is authenticated (see *) in Horizon, > B) User uses said authentication (token) to request another > token from > Keystone, which is displayed under the "API Access" tab on > "Access & > Security". > > > The (token) here could be an OAuth access token. Will look into this (also as per our discussion in Austin). The one issue that has appeared in our continued discussions at home, is the contrast against "service user accounts", that seems a relatively prevalent/common among deployers today, which basically use username/password as the api key credentials, e.g. the authZ of the issued token: If AdminNameless is Domain Admin in their domain, won't their OAuth access token yield keystone tokens with the same authZ as they otherwise have? My presumptive answer being 'yes', brought me to the realization that, if one wants to avoid going the way of "service user accounts" but still reduce authZ, one would like to be able to get OAuth access tokens for a specific project, with a specific role (e.g. "user", or [project-]admin) and the authZ this entails. This would keep the traceability, which is one of the main issues with non-personal accounts. How feasible is this last bit? In general, the primary use case is: - I as a user of openstack on my personal computer retrieve a token to manage openstack client operations without the need of storing my Federation-username/password in local config (nor typing the password in on the keyboard). An extended use case definition of this being: - I as a user of openstack can provision an automated system with these credentials, that can continue to operate as an openstack client for a very long time without maintenance (i.e., either token renewal or VeryLongLifetime). Best, Martin __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation
Hi, we're deploying Liberty (soon Mitaka) with heavy reliance on the SAML2 Federation system by Keystone where we're a Service Provider (SP). The problem in this situation is getting a token for direct API access.(*) There are conceptually two methods to use the CLI: 1) Modify ones (each customer -- in our case O(100)) IdP to add support for a feature called ECP(**), and then use keystoneauth with SAML2 plugin, 2) Go to (for example) "Access & Security / API Access / View Credentials" in Horizon, and check out a token from there. 2) isn't implemented. 1) is a complete blocker for many customers. Are there any principal and fundamental reasons why 2 is not doable? What I imagine needs to happen: A) User is authenticated (see *) in Horizon, B) User uses said authentication (token) to request another token from Keystone, which is displayed under the "API Access" tab on "Access & Security". >From a general perspective, I can't see why this shouldn't work. Whatever scoping the user currently has should be sufficient to check out a similarly-or-lesser scoped token. Anyway, we will, if this is at all doable, bolt this onto our local deployment. I do, A) believe we're not alone with this use case (***), B) look for input on doability. We'll be around in Austin for discussion with Horizon/Keystone regarding this if necessary. Regards, Martin Millnert (* The reason this is a problem: With Federation, there are no local users and passwords in the Keystone database. When authenticating to Horizon in this setup, Keystone (I think) redirects the user to an HTTP page on the home site's Identity Provider (IdP), which performs the authentication. The IdP then signs a set of entitlements about this identity, and sends these back to Keystone. Passwords stay at home. Epic Win.) (** ECP is a new feature, not supported by all IdP's, that at (second) best requires reconfiguration of core authentication services at each customer, and at worst requires customers to change IdP software completely. This is a varying degree of showstopper for various customers.) (*** https://stackoverflow.com/questions/20034143/getting-auth-token-from-keystone-in-horizon https://ask.openstack.org/en/question/51072/get-keystone-auth-token-via-horizon-url/ ) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[Openstack-operators] [logs] graylog rules for openstack?
Hi, we have a Graylog/Elasticsearch setup and are just entering production of our clouds. Seeing, for instance, request ids in some API services logs, I'm curious if there is any published collaborative graylog filters/rules for grabbing these out there? Seems wasteful to re-invent all the time, yet powerful to track requests through several stages (if possible). Also, what are people using for graphing API request latency times? We're on Liberty. Best, Martin Millnert ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [openstack-dev] [all] [dlm] Zookeeper and openjdk, mythbusted
On Mon, 2015-11-09 at 10:19 -0500, Adam Young wrote: > I personally like Java, but feel like we should focus on limiting the > number of languages we need to understand in order to Do OpenStack > development. That's a quite useful datapoint to collect in surveys: How many languages are your components/apps written in? I believe most "serious" production deployments already run Java apps, anyway, for other reasons. I'd wager that basically Erlang and Java are already sunk, in most deployments, in terms of languages, already. It's the cost of operation. -- Martin Millnert __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
