[Openstack-operators] Newton consoleauth HA tokens

[Chris Apsey]

All,

I attempted to deploy the nova service in HA, but when users attempt to 
connect via the console, it doesn't work about 30% of the time and they 
get the 1006 error.  The nova-consoleauth service is reporting their 
token as invalid.  I am running memcached, and have tried referencing it 
using both the legacy memcached_servers directive and in the new [cache] 
configuration section.  No dice.  If I disable the nova-consoleauth 
service on one of the nodes, everything works fine.  I see lots of bug 
reports floating around about this, but I can't quite get the solutions 
I have found reliably working.  I'm on Ubuntu 16.04 LTS+Newton from UCA.


Ideas?

--
v/r

Chris Apsey
bitskr...@bitskrieg.net
https://www.bitskrieg.net

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] OsOps Reboot

[Melvin Hillsman]

Unfortunately I had not requested travel for the PTG but plan to be at the mid 
cycle should nothing change.

--
Melvin Hillsman
Ops Technical Lead
OpenStack Innovation Center
mrhills...@gmail.com
phone: (210) 312-1267
mobile: (210) 413-1659
Learner | Ideation | Belief | Responsibility | Command
http://osic.org

> On Jan 23, 2017, at 18:27, Matt Fischer  wrote:
> 
> Will there be enough of us at the PTG for an impromptu session there as well?
> 
>> On Mon, Jan 23, 2017 at 9:18 AM, Mike Dorman  wrote:
>> +1!  Thanks for driving this.
>> 
>>  
>> 
>>  
>> 
>> From: Edgar Magana 
>> Date: Friday, January 20, 2017 at 1:23 PM
>> To: "m...@mattjarvis.org.uk" , Melvin Hillsman 
>> 
>> 
>> 
>> Cc: OpenStack Operators 
>> Subject: Re: [Openstack-operators] OsOps Reboot
>>  
>> 
>> I super second this! Yes, looking forward to amazing contributions there.
>> 
>>  
>> 
>> Edgar
>> 
>>  
>> 
>> From: Matt Jarvis 
>> Reply-To: "m...@mattjarvis.org.uk" 
>> Date: Friday, January 20, 2017 at 12:33 AM
>> To: Melvin Hillsman 
>> Cc: OpenStack Operators 
>> Subject: Re: [Openstack-operators] OsOps Reboot
>> 
>>  
>> 
>> Great stuff Melvin ! Look forward to seeing this move forward. 
>> 
>>  
>> 
>> On Fri, Jan 20, 2017 at 6:32 AM, Melvin Hillsman  
>> wrote:
>> 
>> Good day everyone,
>> 
>>  
>> 
>> As operators we would like to reboot the efforts started around OsOps. 
>> Initial things that may make sense to work towards are starting back 
>> meetings, standardizing the repos (like having a lib or common folder, 
>> READMEs include release(s) tool works with, etc), increasing feedback loop 
>> from operators in general, actionable work items, identifying teams/people 
>> with resources for continuous testing/feedback, etc.
>> 
>>  
>> 
>> We have got to a great place so let's increase the momentum and maximize all 
>> the work that has been done for OsOps so far. Please visit the following 
>> link [ https://goo.gl/forms/eSvmMYGUgRK901533 ] to vote on day of the week 
>> and time (UTC) you would like to have OsOps meeting. And also visit this 
>> etherpad [ https://etherpad.openstack.org/p/osops-meeting ] to help shape 
>> the initial and ongoing agenda items.
>> 
>>  
>> 
>> Really appreciate you taking time to read through this email and looking 
>> forward to all the great things to come.
>> 
>>  
>> 
>> Also we started an etherpad for brainstorming around how OsOps could/would 
>> function; very rough draft/outline/ideas right now again please provide 
>> feedback: https://etherpad.openstack.org/p/osops-project-future
>> 
>> 
>> 
>> --
>> 
>> Kind regards,
>> 
>> Melvin Hillsman
>> Ops Technical Lead
>> OpenStack Innovation Center
>> 
>> mrhills...@gmail.com
>> phone: (210) 312-1267
>> mobile: (210) 413-1659
>> http://osic.org
>> 
>> Learner | Ideation | Belief | Responsibility | Command
>> 
>> 
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> 
>>  
>> 
>> 
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> 
> 


smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] OsOps Reboot

[Matt Fischer]

Will there be enough of us at the PTG for an impromptu session there as
well?

On Mon, Jan 23, 2017 at 9:18 AM, Mike Dorman  wrote:

> +1!  Thanks for driving this.
>
>
>
>
>
> *From: *Edgar Magana 
> *Date: *Friday, January 20, 2017 at 1:23 PM
> *To: *"m...@mattjarvis.org.uk" , Melvin Hillsman <
> mrhills...@gmail.com>
>
> *Cc: *OpenStack Operators 
> *Subject: *Re: [Openstack-operators] OsOps Reboot
>
>
>
> I super second this! Yes, looking forward to amazing contributions there.
>
>
>
> Edgar
>
>
>
> *From: *Matt Jarvis 
> *Reply-To: *"m...@mattjarvis.org.uk" 
> *Date: *Friday, January 20, 2017 at 12:33 AM
> *To: *Melvin Hillsman 
> *Cc: *OpenStack Operators 
> *Subject: *Re: [Openstack-operators] OsOps Reboot
>
>
>
> Great stuff Melvin ! Look forward to seeing this move forward.
>
>
>
> On Fri, Jan 20, 2017 at 6:32 AM, Melvin Hillsman 
> wrote:
>
> Good day everyone,
>
>
>
> As operators we would like to reboot the efforts started around OsOps.
> Initial things that may make sense to work towards are starting back
> meetings, standardizing the repos (like having a lib or common folder,
> READMEs include release(s) tool works with, etc), increasing feedback loop
> from operators in general, actionable work items, identifying teams/people
> with resources for continuous testing/feedback, etc.
>
>
>
> We have got to a great place so let's increase the momentum and maximize
> all the work that has been done for OsOps so far. Please visit the
> following link [ https://goo.gl/forms/eSvmMYGUgRK901533
> 
> ] to vote on day of the week and time (UTC) you would like to have OsOps
> meeting. And also visit this etherpad [ https://etherpad.openstack.
> org/p/osops-meeting
> 
> ] to help shape the initial and ongoing agenda items.
>
>
>
> Really appreciate you taking time to read through this email and looking
> forward to all the great things to come.
>
>
>
> Also we started an etherpad for brainstorming around how OsOps could/would
> function; very rough draft/outline/ideas right now again please provide
> feedback: https://etherpad.openstack.org/p/osops-project-future
> 
>
>
>
> --
>
> Kind regards,
>
> Melvin Hillsman
> Ops Technical Lead
> OpenStack Innovation Center
>
> mrhills...@gmail.com
> phone: (210) 312-1267
> mobile: (210) 413-1659
> http://osic.org
> 
>
> Learner | Ideation | Belief | Responsibility | Command
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 
>
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Encrypted Cinder Volume Deployment

[Joe Topjian]

Hi Kris,

I came across that as well and I believe it has been fixed and ensures
existing volumes are accessible:

https://github.com/openstack/nova/blob/8c3f775743914fe083371a31433ef5563015b029/releasenotes/notes/bug-1633518-0646722faac1a4b9.yaml

Definitely worthwhile to bring up :)

Joe

On Mon, Jan 23, 2017 at 12:53 PM, Kris G. Lindgren 
wrote:

> Slightly off topic,
>
>
>
> But I remember a discussion involving encrypted volumes and nova(?) and
> there was an issue where an issue/bug where nova was using the wrong key –
> like it got hashed wrong and was using the badly hashed key/password vs’s
> what was configured.
>
>
>
>
>
> ___
>
> Kris Lindgren
>
> Senior Linux Systems Engineer
>
> GoDaddy
>
>
>
> *From: *Joe Topjian 
> *Date: *Monday, January 23, 2017 at 12:41 PM
> *To: *"openstack-operators@lists.openstack.org" <
> openstack-operators@lists.openstack.org>
> *Subject: *[Openstack-operators] Encrypted Cinder Volume Deployment
>
>
>
> Hi all,
>
>
>
> I'm investigating the options for configuring Cinder with encrypted
> volumes and have a few questions.
>
>
>
> The Cinder environment is currently running Kilo which will be upgraded to
> something between M-O later this year. The Kilo release supports the
> fixed_key setting. I see fixed_key is still supported, but has been
> abstracted into Castellan.
>
>
>
> Question: If I configure Kilo with a fixed key, will existing volumes
> still be able to work with that same fixed key in an M, N, O release?
>
>
>
> Next, fixed_key is discouraged because of it being a single key for all
> tenants. My understanding is that Barbican provides a way for each tenant
> to generate their own key.
>
>
>
> Question: If I deploy with fixed_key (either now or in a later release),
> can I move from a master key to Barbican without bricking all existing
> volumes?
>
>
>
> Are there any other issues to be aware of? I've done a bunch of Googling
> and searching on bugs.launchpad.net and am pretty satisfied with the
> current state of support. My intention is to provide users with simple
> native encrypted volume support - not so much supporting uploaded volumes,
> bootable volumes, etc.
>
>
>
> But what I want to make sure of is that I'm not in a position where in
> order to upgrade, a bunch of volumes become irrecoverable.
>
>
>
> Thanks,
>
> Joe
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Encrypted Cinder Volume Deployment

[Kris G. Lindgren]

Slightly off topic,

But I remember a discussion involving encrypted volumes and nova(?) and there 
was an issue where an issue/bug where nova was using the wrong key – like it 
got hashed wrong and was using the badly hashed key/password vs’s what was 
configured.


___
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy

From: Joe Topjian 
Date: Monday, January 23, 2017 at 12:41 PM
To: "openstack-operators@lists.openstack.org" 

Subject: [Openstack-operators] Encrypted Cinder Volume Deployment

Hi all,

I'm investigating the options for configuring Cinder with encrypted volumes and 
have a few questions.

The Cinder environment is currently running Kilo which will be upgraded to 
something between M-O later this year. The Kilo release supports the fixed_key 
setting. I see fixed_key is still supported, but has been abstracted into 
Castellan.

Question: If I configure Kilo with a fixed key, will existing volumes still be 
able to work with that same fixed key in an M, N, O release?

Next, fixed_key is discouraged because of it being a single key for all 
tenants. My understanding is that Barbican provides a way for each tenant to 
generate their own key.

Question: If I deploy with fixed_key (either now or in a later release), can I 
move from a master key to Barbican without bricking all existing volumes?

Are there any other issues to be aware of? I've done a bunch of Googling and 
searching on bugs.launchpad.net and am pretty 
satisfied with the current state of support. My intention is to provide users 
with simple native encrypted volume support - not so much supporting uploaded 
volumes, bootable volumes, etc.

But what I want to make sure of is that I'm not in a position where in order to 
upgrade, a bunch of volumes become irrecoverable.

Thanks,
Joe
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] Encrypted Cinder Volume Deployment

[Joe Topjian]

Hi all,

I'm investigating the options for configuring Cinder with encrypted volumes
and have a few questions.

The Cinder environment is currently running Kilo which will be upgraded to
something between M-O later this year. The Kilo release supports the
fixed_key setting. I see fixed_key is still supported, but has been
abstracted into Castellan.

Question: If I configure Kilo with a fixed key, will existing volumes still
be able to work with that same fixed key in an M, N, O release?

Next, fixed_key is discouraged because of it being a single key for all
tenants. My understanding is that Barbican provides a way for each tenant
to generate their own key.

Question: If I deploy with fixed_key (either now or in a later release),
can I move from a master key to Barbican without bricking all existing
volumes?

Are there any other issues to be aware of? I've done a bunch of Googling
and searching on bugs.launchpad.net and am pretty satisfied with the
current state of support. My intention is to provide users with simple
native encrypted volume support - not so much supporting uploaded volumes,
bootable volumes, etc.

But what I want to make sure of is that I'm not in a position where in
order to upgrade, a bunch of volumes become irrecoverable.

Thanks,
Joe
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] What would you like in Pike?

[Matt Riedemann]

On 1/18/2017 3:06 PM, Sam Morrison wrote:

I would love it if all the projects policy.json was actually usable. Too
many times the policy.json isn’t the only place where authN happens with
lots of hard coded is_admin etc.

Just the ability to to have a certain role to a certain thing would be
amazing. It makes it really hard to have read only users to generate
reports with that we can show our funders how much people use our
openstack cloud.

Cheers,
Sam
(non-enterprise)



Sam,

I'd like to get your feedback on the policy-in-code changes for Nova in 
the Newton release along with the related Nova policy CLIs. Some of that 
is probably not well documented or communicated, but it was trying to 
build into a place where you can get more information about what an 
individual user or project is able to do with Nova from an access 
perspective. The immediate benefit with policy-in-code was simplifying 
your policy file such that it can be empty if you are just going with 
the defaults, and then only add/change the defaults as needed in the 
policy.json (or policy.yaml). There was some other discussion on 
long-term goals for policy at the Austin summit which I could dig up if 
needed.


--

Thanks,

Matt Riedemann


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] Glance swift multi-user storage backend survey

[Brian Rosmaita]

Hello operators,

The Glance team is conducting another survey about Glance usage.  This
one is for operators who are currently using (or contemplating using)
the swift multi-tenant storage backend for Glance, a feature which is
*not* enabled by default.

The survey is only 5 questions long, so it won't take much time to fill out.

https://goo.gl/forms/WJh6PvRw4f42mStc2

The survey will be open until 23:59 UTC on 31 January 2017.


thanks,
brian



___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] OsOps Reboot

[Mike Dorman]

+1!  Thanks for driving this.


From: Edgar Magana 
Date: Friday, January 20, 2017 at 1:23 PM
To: "m...@mattjarvis.org.uk" , Melvin Hillsman 

Cc: OpenStack Operators 
Subject: Re: [Openstack-operators] OsOps Reboot

I super second this! Yes, looking forward to amazing contributions there.

Edgar

From: Matt Jarvis 
Reply-To: "m...@mattjarvis.org.uk" 
Date: Friday, January 20, 2017 at 12:33 AM
To: Melvin Hillsman 
Cc: OpenStack Operators 
Subject: Re: [Openstack-operators] OsOps Reboot

Great stuff Melvin ! Look forward to seeing this move forward.

On Fri, Jan 20, 2017 at 6:32 AM, Melvin Hillsman 
mailto:mrhills...@gmail.com>> wrote:
Good day everyone,

As operators we would like to reboot the efforts started around OsOps. Initial 
things that may make sense to work towards are starting back meetings, 
standardizing the repos (like having a lib or common folder, READMEs include 
release(s) tool works with, etc), increasing feedback loop from operators in 
general, actionable work items, identifying teams/people with resources for 
continuous testing/feedback, etc.

We have got to a great place so let's increase the momentum and maximize all 
the work that has been done for OsOps so far. Please visit the following link [ 
https://goo.gl/forms/eSvmMYGUgRK901533
 ] to vote on day of the week and time (UTC) you would like to have OsOps 
meeting. And also visit this etherpad [ 
https://etherpad.openstack.org/p/osops-meeting
 ] to help shape the initial and ongoing agenda items.

Really appreciate you taking time to read through this email and looking 
forward to all the great things to come.

Also we started an etherpad for brainstorming around how OsOps could/would 
function; very rough draft/outline/ideas right now again please provide 
feedback: 
https://etherpad.openstack.org/p/osops-project-future


--
Kind regards,

Melvin Hillsman
Ops Technical Lead
OpenStack Innovation Center

mrhills...@gmail.com
phone: (210) 312-1267
mobile: (210) 413-1659
http://osic.org

Learner | Ideation | Belief | Responsibility | Command

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] allowed_address_pairs for port in neutron

[Dale Smith]

Hi George,

It would be worth checking to see if that extension is available in your
installation:

$ openstack extension list --network -c Name -c Alias
+---+---+
| Name | Alias |
+---+---+
... | Allowed Address Pairs | allowed-address-pairs |
...

We've documented a full working example here, which may be useful, but I
can't see anything incorrect with your request.
http://docs.catalystcloud.io/tutorials/deploying-highly-available-instances-with-keepalived.html#allowed-address-pairs
(see further down under 'Virtual Address Setup' for CLI command
examples) cheers, Dale
On 23/01/17 10:41, George Shuklin wrote:
> Hello. I'm trying to allow more than one IP on interface for tenant,
> but neutron (Mitaka) rejects my requests: $ neutron port-update
> b59bc3bb-7d34-4fbb-8e55-a9f1c5c88411 --allowed-address-pairs type=dict
> list=true ip_address=10.254.15.4 Unrecognized attribute(s)
> 'allowed_address_pairs' Neutron server returns request_ids:
> ['req-9168f1f4-6e78-42fb-8521-c69b1cfd4f67'] Is someone done this? Can
> you show your commands to neutron and name version you are using?
> Thanks. ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators 
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] allowed_address_pairs for port in neutron

[shiva m]

I have used the same way on Juno,  it worked for me.

neutron port-update 63c9933f-7ecb-4f29-9a34-faece384530d \
--allowed-address-pairs type=dict list=true \
mac_address='fa:16:3e:89:11:22',ip_address='10.0.2.0/24' \
mac_address='fa:16:3e:89:33:44',ip_address='10.0.3.0/24'

Thanks,
Shiva


On Mon, Jan 23, 2017 at 4:11 PM, George Shuklin 
wrote:

> Hello.
>
> I'm trying to allow more than one IP on interface for tenant, but neutron
> (Mitaka) rejects my requests:
>
> $ neutron port-update b59bc3bb-7d34-4fbb-8e55-a9f1c5c88411
> --allowed-address-pairs type=dict list=true ip_address=10.254.15.4
>
> Unrecognized attribute(s) 'allowed_address_pairs'
> Neutron server returns request_ids: ['req-9168f1f4-6e78-42fb-8521-
> c69b1cfd4f67']
>
> Is someone done this? Can you show your commands to neutron and name
> version you are using?
>
>
> Thanks.
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] allowed_address_pairs for port in neutron

[George Shuklin]

Hello.

I'm trying to allow more than one IP on interface for tenant, but 
neutron (Mitaka) rejects my requests:


$ neutron port-update b59bc3bb-7d34-4fbb-8e55-a9f1c5c88411 
--allowed-address-pairs type=dict list=true ip_address=10.254.15.4


Unrecognized attribute(s) 'allowed_address_pairs'
Neutron server returns request_ids: 
['req-9168f1f4-6e78-42fb-8521-c69b1cfd4f67']


Is someone done this? Can you show your commands to neutron and name 
version you are using?



Thanks.


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-operators][openstack-ansible] Optioanal services documentation for Newton

[Salman Toor]

Hi,

Thanks Melvin! I already been to these links and I don’t think these links 
contains the information about optional services. For example FWaaS, LBaaS or 
even Ceilometer.

Those are what I am looking for the Newton release. Mitaka version works fine 
but just want to check if there is any change in the Newton.

Regards..
Salman.


PhD, Scientific Computing
Researcher, IT Department,
Uppsala University.
Senior Cloud Architect,
SNIC.
Cloud Application Expert,
UPPMAX.
salman.t...@it.uu.se
http://www.it.uu.se/katalog/salto690


On Jan 23, 2017, at 5:08 AM, Melvin Hillsman 
mailto:mrhills...@gmail.com>> wrote:

Hey Salman,

Maybe this will help - 
http://docs.openstack.org/project-deploy-guide/openstack-ansible/newton/ - the 
documentation has changed a bit since Newton ( 
http://docs.openstack.org/developer/openstack-ansible/newton/ )

On Sun, Jan 22, 2017 at 2:12 PM, Salman Toor 
mailto:salman.t...@it.uu.se>> wrote:
Hi,

Wondering can someone help me pointing the openstack-ansible (Newton) guide for 
optional services? I have found for Mitaka but not for Newton.

Basically looking for a similar link for Newton (Following is for Mitaka):

http://docs.openstack.org/developer/openstack-ansible/mitaka/install-guide/configure.html

Regards..
Salman.



PhD, Scientific Computing
Researcher, IT Department,
Uppsala University.
Senior Cloud Architect,
SNIC.
Cloud Application Expert,
UPPMAX.
salman.t...@it.uu.se
http://www.it.uu.se/katalog/salto690

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators




--
Kind regards,

Melvin Hillsman
Ops Technical Lead
OpenStack Innovation Center

mrhills...@gmail.com
phone: (210) 312-1267
mobile: (210) 413-1659
http://osic.org

Learner | Ideation | Belief | Responsibility | Command

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators