Re: [openstack-dev] [tc][appcat] The future of the App Catalog
This might be related to the current discussion. In one of the keystone PTG sessions we started to talk about API keys. [0] A spec is being written and discussed. [1] This would allow the user to provision API key credentials with a subset of roles for use inside of their applications. Removing the need to inject the actual user credentials inside an application. [0] http://lbragstad.com/keystone-pike-ptg-summary/ [1] https://review.openstack.org/#/c/438761 > On Mar 15, 2017, at 8:45 AM, Sean Dague wrote: > > On 03/13/2017 05:10 PM, Zane Bitter wrote: >> >> Demo please! >> >> Most Keystone backends are read-only, you can't even create a new user >> account yourself. It's an admin-only API anyway. The only non-expiring >> credential you even *have*, ignoring the difficulties of getting it to >> the server, is your LDAP password. Would *you* put *your* LDAP password >> on an internet-facing server? I would not. > > So is one of the issues to support cloud native flows that our user auth > system, which often needs to connect into traditional enterprise > systems, doesn't really consider that? > > I definitely agree, if your cloud is using your LDAP password, which > gets you into your health insurance and direct deposit systems at your > employeer, sticking this into a cloud server is a no go. > > Thinking aloud, I wonder if user provisionable sub users would help > here. They would have all the same rights as the main user (except > modify other subusers), but would have a dedicated user provisioned > password. You basically can carve off the same thing from Google when > you have services that can't do the entire oauth/2factor path. Fastmail > rolled out something similar recently as well. > > -Sean > > -- > Sean Dague > http://dague.net > > __ > 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 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] [keystone] broken python35 job due to webob compatibility issues
The patch merged and the gate is now unblocked. > On Mar 29, 2017, at 5:54 PM, Lance Bragstad wrote: > > The keystone gate is currently broken [0]. This seems related to a previous > change we made to be compatible with webob 1.7 [1]. Looks like we missed a > couple spots in the original patch that are failing now that we're using a > newer version of webob. > > There is a solution up for review [2] that should unblock the gate. > > [0] > http://logs.openstack.org/44/443344/6/gate/gate-keystone-python35/e162b3d/testr_results.html.gz > [1] https://review.openstack.org/#/c/422234/ > [2] https://review.openstack.org/#/c/451559/ > __ > 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 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] help required regarding devstack
Hi, I do not know about VM migration, however for restarting nova the right service names are devstack@n-api, devstack@n-cpu, etc. ubuntu@k2k1:~$ systemctl list-units | grep devstack devstack@c-api.service loaded active running Devstack devstack@c-api.service devstack@c-sch.service loaded active running Devstack devstack@c-sch.service devstack@c-vol.service loaded active running Devstack devstack@c-vol.service devstack@dstat.service loaded active running Devstack devstack@dstat.service devstack@etcd.service loaded active running Devstack devstack@etcd.service devstack@g-api.service loaded active running Devstack devstack@g-api.service devstack@g-reg.service loaded active running Devstack devstack@g-reg.service devstack@keystone.service loaded active running Devstack devstack@keystone.service devstack@n-api-meta.service loaded active running Devstack devstack@n-api-meta.service devstack@n-api.service loaded active running Devstack devstack@n-api.service devstack@n-cauth.service loaded active running Devstack devstack@n-cauth.service devstack@n-cond.service loaded active running Devstack devstack@n-cond.service devstack@n-cpu.service loaded active running Devstack devstack@n-cpu.service devstack@n-novnc.service loaded active running Devstack devstack@n-novnc.service devstack@n-sch.service loaded active running Devstack devstack@n-sch.service devstack@placement-api.service loaded active running Devstack devstack@placement-api.service devstack@q-agt.service loaded active running Devstack devstack@q-agt.service devstack@q-dhcp.service loaded active running Devstack devstack@q-dhcp.service devstack@q-l3.service loaded active running Devstack devstack@q-l3.service devstack@q-meta.service loaded active running Devstack devstack@q-meta.service devstack@q-svc.service loaded active running Devstack devstack@q-svc.service system-devstack.slice loaded active activesystem-devstack.slice > On Jul 24, 2017, at 9:43 AM, Ziad Nayyer wrote: > > Dear, > > I am a PhD candidate at COMSATS, lahore, Pakistan. I am working on devstack. > Just wanted to know whether it supports VM Migration between two devstacks > installed on two different physical machines as currently I am unable to find > any lead. Also please let me know how to restart a particular service on > devstack version pike on centos7. > > The screen file is not being generated in devstack folder ->stack-screenrc > and systemctl only restarts keystone not any other like nova-compute > > sudo systemctl restart devstack@keystone (works) > sudo systemctl restart devstack@nova > sudo systemctl restart devstack@nova-compute > > and any other does not work. > > I'll be very thankful. > > > -- > Regards, > > Muhammad Ziad Nayyer Dar > __ > 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 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] [keystone][api] Backwards incompatible changes based on config
Is this the case even if we haven’t made any final release with the change that introduced this issue? [0] It was only included in the Pike milestones and betas so far, and was not part of the Ocata release. Therefore the call which now returns a 403 in master, returned a 2xx in Ocata. So we would be fixing something which is broken on master rather than changing a ‘contract’. 0. https://github.com/openstack/keystone/commit/51d5597df729158d15b71e2ba80ab103df5d55f8 > On Aug 4, 2017, at 3:52 PM, Matthew Treinish wrote: > > On Fri, Aug 04, 2017 at 03:35:38PM -0400, William M Edmonds wrote: >> >> Lance Bragstad wrote on 08/04/2017 02:37:40 PM: >>> Properly fixing this would result in a 403 -> 204 status code, which >>> requires an API version bump according to the interoperability >>> guidelines [5] (note that keystone has not implemented microversions at >>> this point). At the same time - not fixing the issues results in a 403 >>> anytime a project is deleted while in this configuration. >>> >> >> The guidelines you linked actually say that this is allowed without a >> version bump: >> >> "There are two types of change which do not require a version change:... or >> responding with success (when the request was properly formed, but the >> server had broken handling)." > > That's only for 500-599 response codes. The 'broken handling' there literally > means broken as in the server couldn't handle the request. That bullet point > is > saying if you had a 500-599 response fixing the code so it's either a 4XX or a > 2XX does not need a version. This specific case needs a version boundary > because > you going from a 403 -> 204. > > -Matt Treinish > __ > 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 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] [policy] AWS IAM session
+1 -- Kristi Nikolla Software Engineer @ massopen.cloud kri...@nikolla.me On Wed, Oct 4, 2017, at 10:08 AM, Zane Bitter wrote: > On 03/10/17 16:08, Lance Bragstad wrote: > > Hey all, > > > > It was mentioned in today's keystone meeting [0] that it would be useful > > to go through AWS IAM (or even GKE) as a group. With all the recent > > policy discussions and work, it seems useful to get our eyes on another > > system. The idea would be to spend time using a video conference/screen > > share to go through and play with policy together. The end result should > > keep us focused on the implementations we're working on today, but also > > provide clarity for the long-term vision of OpenStack's RBAC system. > > > > Are you interested in attending? If so, please respond to the thread. > > Once we have some interest, we can gauge when to hold the meeting, which > > tools we can use, and setting up a test IAM account. > > +1, I'd like to attend this. > > Also I highly recommend > http://start.jcolemorrison.com/aws-iam-policies-in-a-nutshell/ over the > actual AWS docs as a compact reference. > > - ZB > > > Thanks, > > > > Lance > > > > [0] > > http://eavesdrop.openstack.org/meetings/keystone/2017/keystone.2017-10-03-18.00.log.html#l-119 > > > > > > > > > > __ > > 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 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 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] [keystone] Signing off
Thank you for all your invaluable contributions Henry. It has been a pleasure working with you. Best of luck! Kristi ‐‐‐ Original Message ‐‐‐ On May 30, 2018 4:45 AM, Henry Nash wrote: > Hi > > It is with a somewhat heavy heart that I have decided that it is time to hang > up my keystone core status. Having been involved since the closing stages of > Folsom, I've had a good run! When I look at how far keystone has come since > the v2 days, it is remarkable - and we should all feel a sense of pride in > that. > > Thanks to all the hard work, commitment, humour and support from all the > keystone folks over the years - I am sure we will continue to interact and > meet among the many other open source projects that many of us are becoming > involved with. Ad astra! > > Best regards, > > Henry > Twitter: @henrynash > linkedIn: www.linkedin.com/in/henrypnash > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU__ 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] [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible architectures for image synchronisation
Answering here questions related to mixmatch, as I'm the main developer. - If I understood [[1](https://mixmatch.readthedocs.io/en/latest/)] correctly mixmatch can help Nova to attach a remote volume, but it will not help in synchronizing the images. is this true? Correct, it will not synchronize images. What it does is forward API requests across OpenStack clouds, allowing Nova to fetch a remote image. It could be enhanced to "cache" the image, in which case it would be the PULL model. In this architecture, you would have mixmatch acting as a proxy to one or multiple Glance API servers (some remote), and you could even potentially forego having a Glance at all in the edge cloud. - Not sure ... but I didn’t think this was the model being used in mixmatch ... thought mixmatch was more the PULL model (below) - [G0]: Yes, this is more or less my understanding. I remove the mixmatch reference from this chapter. Rather than remove it completely you could move it to the correct section. :) ‐‐‐ Original Message ‐‐‐ On June 11, 2018 10:28 AM, Csatari, Gergely (Nokia - HU/Budapest) wrote: > Hi, > > Thanks for the comments. > > I’ve updated the wiki: > https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#Several_Glances_with_an_independent_syncronisation_service.2C_synch_using_the_backend > > Br, > > Gerg0 > > [ ] > > From: Waines, Greg [mailto:greg.wai...@windriver.com] > Sent: Friday, June 8, 2018 1:46 PM > To: Csatari, Gergely (Nokia - HU/Budapest) ; > OpenStack Development Mailing List (not for usage questions) > ; edge-comput...@lists.openstack.org > Subject: Re: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible > architectures for image synchronisation > > Responses in-lined below, > > Greg. > > From: "Csatari, Gergely (Nokia - HU/Budapest)" > Date: Friday, June 8, 2018 at 3:39 AM > To: Greg Waines , > "openstack-dev@lists.openstack.org" , > "edge-comput...@lists.openstack.org" > Subject: RE: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible > architectures for image synchronisation > > Hi, > > Going inline. > > From: Waines, Greg [mailto:greg.wai...@windriver.com] > Sent: Thursday, June 7, 2018 2:24 PM > > I had some additional questions/comments on the Image Synchronization Options > ( https://wiki.openstack.org/wiki/Image_handling_in_edge_environment ): > > One Glance with multiple backends > > - In this scenario, are all Edge Clouds simply configured with the one > central glance for its GLANCE ENDPOINT ? > > - i.e. GLANCE is a typical shared service in a multi-region environment ? > > [G0]: In my understanding yes. > > - If so, > how does this OPTION support the requirement for Edge Cloud Operation when > disconnected from Central Location ? > > [G0]: This is an open question for me also. > > Several Glances with an independent synchronization service(PUSH) > > - I refer to this as the PUSH model > > - I don’t believe you have to ( or necessarily should) rely on the backend to > do the synchronization of the images > > - i.e. the ‘Synch Service’ could do this strictly through Glance REST APIs > (making it independent of the particular Glance backend ... and allowing the > Glance Backends at Central and Edge sites to actually be different) > > [G0]: Okay, I can update the wiki to reflect this. Should we keep the > “synchronization by the backend” option as an other alternative? > [Greg] Yeah we should keep it as an alternative. > > - I think the ‘Synch Service’ MUST be able to support ‘selective/multicast’ > distribution of Images from Central to Edge for Image Synchronization > > - i.e. you don’t want Central Site pushing ALL images to ALL Edge Sites ... > especially for the small Edge Sites > > [G0]: Yes, the question is how to define these synchronization policies. > [Greg] Agreed ... we’ve had some very high-level discussions with end users, > but haven’t put together a proposal yet. > > - Not sure ... but I didn’t think this was the model being used in mixmatch > ... thought mixmatch was more the PULL model (below) > > [G0]: Yes, this is more or less my understanding. I remove the mixmatch > reference from this chapter. > > One Glance and multiple Glance API Servers (PULL) > > - I refer to this as the PULL model > > - This is the current model supported in StarlingX’s Distributed Cloud > sub-project > > - We run glance-api on all Edge Clouds ... that talk to glance-registry on > the Central Cloud, and > > - We have glance-api setup for caching such that only the first access to an > particular image incurs the latency of the image transfer from Central to Edge > > [G0]: Do you do image caching in Glance API or do you rely in the image cache > in Nova? In the Forum session there were some discussions about this and I > think the conclusion was that using the image cache of Nova is enough. > [Greg] We enabled image caching in the Glance API. > I believe that Nova Image Caching caches at the co
Re: [openstack-dev] [nova] about filter the flavor
OSC here refers to OpenStackClient [0]. [0]. https://docs.openstack.org/python-openstackclient/latest/ On Fri, Jul 6, 2018 at 4:44 AM Rambo wrote: > > Does the "OSC“ meas the osc placement? > > > -- Original -- > From: "Matt Riedemann"; > Date: Mon, Jul 2, 2018 10:36 PM > To: "OpenStack Developmen"; > Subject: Re: [openstack-dev] [nova] about filter the flavor > > On 7/2/2018 2:43 AM, 李杰 wrote: > > Oh,sorry,not this means,in my opinion,we could filter the flavor in > > flavor list.such as the cli:openstack flavor list --property key:value. > > There is no support for natively filtering flavors by extra specs in the > compute REST API so that would have to be added with a microversion (if > we wanted to add that support). So it would require a nova spec, which > would be reviewed for consideration at the earliest in the Stein > release. OSC could do client-side filtering if it wanted. > > -- > > Thanks, > > Matt > > __ > 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 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 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] [Openstack] [nova][api] Novaclient redirect endpoint https into http
On Thu, Jul 5, 2018 at 4:11 PM Monty Taylor wrote:
>
> On 07/05/2018 01:55 PM, melanie witt wrote:
> > +openstack-dev@
> >
> > On Wed, 4 Jul 2018 14:50:26 +, Bogdan Katynski wrote:
> >>> But, I can not use nova command, endpoint nova have been redirected
> >>> from https to http. Here:http://prntscr.com/k2e8s6 (command: nova
> >>> –insecure service list)
> >> First of all, it seems that the nova client is hitting /v2.1 instead
> >> of /v2.1/ URI and this seems to be triggering the redirect.
> >>
> >> Since openstack CLI works, I presume it must be using the correct URL
> >> and hence it’s not getting redirected.
> >>
> >>> And this is error log: Unable to establish connection
> >>> tohttp://192.168.30.70:8774/v2.1/: ('Connection aborted.',
> >>> BadStatusLine("''",))
> >> Looks to me that nova-api does a redirect to an absolute URL. I
> >> suspect SSL is terminated on the HAProxy and nova-api itself is
> >> configured without SSL so it redirects to an http URL.
> >>
> >> In my opinion, nova would be more load-balancer friendly if it used a
> >> relative URI in the redirect but that’s outside of the scope of this
> >> question and since I don’t know the context behind choosing the
> >> absolute URL, I could be wrong on that.
> >
> > Thanks for mentioning this. We do have a bug open in python-novaclient
> > around a similar issue [1]. I've added comments based on this thread and
> > will consult with the API subteam to see if there's something we can do
> > about this in nova-api.
>
> A similar thing came up the other day related to keystone and version
> discovery. Version discovery documents tend to return full urls - even
> though relative urls would make public/internal API endpoints work
> better. (also, sometimes people don't configure things properly and the
> version discovery url winds up being incorrect)
>
> In shade/sdk - we actually construct a wholly-new discovery url based on
> the url used for the catalog and the url in the discovery document since
> we've learned that the version discovery urls are frequently broken.
>
> This is problematic because SOMETIMES people have public urls deployed
> as a sub-url and internal urls deployed on a port - so you have:
>
> Catalog:
> public: https://example.com/compute
> internal: https://compute.example.com:1234
>
> Version discovery:
> https://example.com/compute/v2.1
>
> When we go to combine the catalog url and the versioned url, if the user
> is hitting internal, we product
> https://compute.example.com:1234/compute/v2.1 - because we have no way
> of systemically knowing that /compute should also be stripped.
>
> VERY LONG WINDED WAY of saying 2 things:
>
> a) Relative URLs would be *way* friendlier (and incidentally are
> supported by keystoneauth, openstacksdk and shade - and are written up
> as being a thing people *should* support in the documents about API
> consumption)
>
> b) Can we get agreement that changing behavior to return or redirect to
> a relative URL would not be considered an api contract break? (it's
> possible the answer to this is 'no' - so it's a real question)
If the answer is 'no', can we find a process that gets us there? Or
are we doomed
by the inability to version the version document?
>
> Monty
>
> __
> 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 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] [keystone] new keystone core (breton)
Congrats Boris! Well deserved! Kristi On 10/31/2016 03:46 PM, Steve Martinelli wrote: > I want to welcome Boris Bobrov (breton) to the keystone core team. Boris > has been a contributor for some time and is well respected by the > keystone team for bringing real-world operator experience and feedback. > He has recently become more active in terms of code contributions and > bug triaging. Upon interacting with Boris, you quickly realize he has a > high standard for quality and keeps us honest. > > Thanks for all your hard work Boris, I'm happy to have you on the team. > > Steve Martinelli > stevemar > > > > __ > 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 > signature.asc Description: OpenPGP digital signature __ 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] [all] Bringing the community together (combine the lists!)
I’m strongly in support of merging the lists. > On Aug 30, 2018, at 2:57 PM, Chris Friesen > wrote: > > On 08/30/2018 11:03 AM, Jeremy Stanley wrote: > >> The proposal is simple: create a new openstack-discuss mailing list >> to cover all the above sorts of discussion and stop using the other >> four. > > Do we want to merge usage and development onto one list? That could be a > busy list for someone who's just asking a simple usage question. True, but it would bring more visibility to the developers about troubles that users are having. > > Alternately, if we are going to merge everything then why not just use the > "openstack" mailing list since it already exists and there are references to > it on the web. > > (Or do you want to force people to move to something new to make them > recognize that something has changed?) > > Chris > > __ > 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 signature.asc Description: Message signed with OpenPGP __ 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] [election] [tc] TC Candidacy
Hi all, I’m stepping out of the comfort zone and submitting my candidacy for a seat on the OpenStack Technical Committee. I’m a software architect at the Mass Open Cloud[0], a collaboration between the five major universities of the Boston area to create and operate a public cloud based on the Open Cloud eXchange model[1]. I’ve been involved with OpenStack for the past three years as a user, operator and developer. My main area of focus is in identity and federation. I’m a core reviewer for the Keystone project and the lead for MixMatch[2][3][4], which aims to enable resource federation among multiple OpenStack deployments. I believe my affiliation with academia and research will bring a different voice to the technical committee from a mostly underrepresented group. Furthermore, my experience with federation and operating a cloud with a diverse set of offerings not limited to OpenStack, but including other important pieces of a cloud provider’s toolbox will prove really valuable, especially with the vision dilemmas that OpenStack is facing today. I’m really excited to have the opportunity to take part in the discussion with regards to the technical vision for OpenStack. Regardless of election outcome, this is the first step towards a larger involvement from me in the important discussions (no more shying away from the important mailing list threads.) I have a lot yet to learn, and consider it a big privilege to be surrounded by so many kind people who have mentored me and continue to mentor me while I walk and stumble. I strongly believe in servant leadership, and I will devote myself in helping the community and mentoring the next wave of OpenStack contributors. I have found OpenStack to be one of the most welcoming online communities, and am very proud to be a part of this big family and for a chance to give back. Thank you for your time and attention, Kristi Nikolla (knikolla) [0]. https://massopen.cloud [1]. http://www.cs.bu.edu/fac/best/res/papers/ic14.pdf [2]. https://mixmatch.readthedocs.io [3]. https://github.com/openstack/mixmatch [4]. https://youtu.be/O0euqskJJ_8 signature.asc Description: Message signed with OpenPGP __ 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] [election] [tc] TC Candidacy
Thanks for the question Matt, I have to agree that that is not a good use of time, which is why I’m really interested in the Constellations initiative. There doesn’t have to be a very specifically defined “what OpenStack is” answer, but instead we can focus on multiple answers based on the features we offer and the multitude of problems that we solve. Furthermore, I think that constellations will help weaken the silos between teams by increasing cross-project collaboration and integration towards a common goal. Ultimately, to me, what OpenStack is, first and foremost, is a community. Additionally, I would like to be much more involved with the process of welcoming and mentoring new contributors, and the various groups formed around that. Working in academia, gives me access to a large pool of students, especially during the cloud computing course that we offer in two universities of the Boston area. Many of our previous alums (me included) end up becoming regular contributors and continuing their work in OpenStack and other open source communities. Ultimately, this list isn’t exclusive and I’d love to hear your and other people's opinions about what you think the I should focus on. Kristi Nikolla > On Sep 7, 2018, at 7:26 AM, Matt Riedemann wrote: > > On 9/5/2018 1:20 PM, Kristi Nikolla wrote: >> I’m really excited to have the opportunity to take part in the discussion >> with >> regards to the technical vision for OpenStack. Regardless of election >> outcome, >> this is the first step towards a larger involvement from me in the important >> discussions (no more shying away from the important mailing list threads.) > > I'm not trying to pick on you Kristi, but personally I'm tired of the TC > vision question that's been going on for years now and would like the people > I vote for to spend less time talking about OpenStack and what it is or what > it isn't (because that changes based on the person you talk to and on what > day you ask them), and spend more time figuring out how to move cross-project > initiatives forward. So whether or not OpenStack is a toolkit for > private/public/edge clouds, or a product, or something else, there are likely > common themes within OpenStack that we can generally agree on across projects > and need people to work on them, rather than just talk about doing them. Are > there specific cross-project initiatives you are interested in working on? > > -- > > Thanks, > > Matt > > __ > 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 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
