How to add yourself to Planet OpenStack: https://wiki.openstack.org/wiki/AddingYourBlog
As for SuperUser you could reach out to them if you think it's interesting for users/operators. Generally they'll want to publish it there first then you follow-up with your blog post a few days later. On Mon, Nov 7, 2016 at 8:17 AM, Lance Bragstad <lbrags...@gmail.com> wrote: > That's a good idea. Is there a page detailing the process for contributing > to the OpenStack Blog? I did some checking but haven't found any resources > yet. I also asked in #openstack and #openstack-doc. > > On Thu, Nov 3, 2016 at 11:04 AM, Rochelle Grober < > rochelle.gro...@huawei.com> wrote: > >> a blog post on the OpenStack sore might be good. superuser? there are >> folks reading this who can help >> >> Sent from HUAWEI AnyOffice >> *From:*Lance Bragstad >> *To:*OpenStack Development Mailing List (not for usage questions), >> openstack-operat...@lists.openstack.org, >> *Date:*2016-11-03 08:11:20 >> *Subject:*Re: [openstack-dev] [keystone][tripleo][ansible][puppet][all] >> changing default token format >> >> I totally agree with communicating this the best we can. I'm adding the >> operator list to this thread to increase visibility. >> >> If there are any other methods folks think of for getting the word out, >> outside of what we've already done (release notes, email threads, etc.), >> please let me know. I'd be happy to drive those communications. >> >> On Thu, Nov 3, 2016 at 9:45 AM, Alex Schultz <aschu...@redhat.com> wrote: >> >>> Hey Steve, >>> >>> On Thu, Nov 3, 2016 at 8:29 AM, Steve Martinelli <s.martine...@gmail.com> >>> wrote: >>> > Thanks Alex and Emilien for the quick answer. This was brought up at >>> the >>> > summit by Adam, but I don't think we have to prevent keystone from >>> changing >>> > the default. TripleO and Puppet can still specify UUID as their desired >>> > token format; it is not deprecated or slated for removal. Agreed? >>> > >>> >>> My email was not to tell you to stop.I was just letting you know that >>> your change does not affect the puppet modules because we define our >>> default as UUID. It was just as a heads up to others on this email >>> that this change should not affect anyone consuming the puppet modules >>> because our default is still UUID and will be even after keystone's >>> default changes. >>> >>> Thanks, >>> -Alex >>> >>> > On Thu, Nov 3, 2016 at 10:23 AM, Alex Schultz <aschu...@redhat.com> >>> wrote: >>> >> >>> >> Hey Steve, >>> >> >>> >> On Thu, Nov 3, 2016 at 8:11 AM, Steve Martinelli < >>> s.martine...@gmail.com> >>> >> wrote: >>> >> > As a heads up to some of keystone's consuming projects, we will be >>> >> > changing >>> >> > the default token format from UUID to Fernet. Many patches have >>> merged >>> >> > to >>> >> > make this possible [1]. The last 2 that you probably want to look >>> at are >>> >> > [2] >>> >> > and [3]. The first flips a switch in devstack to make fernet the >>> >> > selected >>> >> > token format, the second makes it default in Keystone itself. >>> >> > >>> >> > [1] https://review.openstack.org/#/q/topic:make-fernet-default >>> >> > [2] DevStack patch: https://review.openstack.org/#/c/367052/ >>> >> > [3] Keystone patch: https://review.openstack.org/#/c/345688/ >>> >> > >>> >> >>> >> Thanks for the heads up. In puppet openstack we had already >>> >> anticipated this and attempted to do the same for the >>> >> puppet-keystone[0] module as well. Unfortunately after merging it, we >>> >> found that tripleo wasn't yet prepared to handle the HA implementation >>> >> of fernet tokens so we had to revert it[1]. This shouldn't impact >>> >> anyone currently consuming puppet-keystone as we define uuid as the >>> >> default for now. Our goal is to do something similar this cycle but >>> >> there needs to be some further work in the downstream consumers to >>> >> either define their expected default (of uuid) or support fernet key >>> >> generation correctly. >>> >> >>> >> Thanks, >>> >> -Alex >>> >> >>> >> [0] https://review.openstack.org/#/c/389322/ >>> >> [1] https://review.openstack.org/#/c/392332/ >>> >> >>> >> > >>> >> > ____________________________________________________________ >>> ______________ >>> >> > 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.op >>> enstack.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.op >>> enstack.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.op >>> enstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> > > _______________________________________________ > OpenStack-operators mailing list > openstack-operat...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > >
__________________________________________________________________________ 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