Open Stack

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 <lbragstad at 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.grober at 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-operators at 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 <aschultz at redhat.com> wrote:
>>
>>> Hey Steve,
>>>
>>> On Thu, Nov 3, 2016 at 8:29 AM, Steve Martinelli <s.martinelli at 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 <aschultz at redhat.com>
>>> wrote:
>>> >>
>>> >> Hey Steve,
>>> >>
>>> >> On Thu, Nov 3, 2016 at 8:11 AM, Steve Martinelli <
>>> s.martinelli at 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-request at 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-request at 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-request at 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-request at lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20161107/2d4b2300/attachment.html>