Re: [Openstack-operators] [openstack-dev] [nova] reset key pair during rebuilding

[Marcus Furlong]

On 27 September 2017 at 09:23, Michael Still <mi...@stillhq.com> wrote:
>
> Operationally, why would I want to inject a new keypair? The scenario I can
> think of is that there's data in that instance that I want, and I've lost
> the keypair somehow. Unless that data is on an ephemeral, its gone if we do
> a rebuild.

This is quite a common scenario - staff member who started the
instance leaves, and you want to access data on the instance, or
maintain/debug the service running on the instance.

Hitherto, I have used direct db calls to update the key, so it would
be nice if there was an API call to do so.

Cheers,
Marcus.
-- 
Marcus Furlong

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

Re: [Openstack-operators] backup to object store - tool recommendations

[Marcus Furlong]

On 27 March 2017 at 22:39, Blair Bethwaite <blair.bethwa...@gmail.com> wrote:
> Hi all,
>
> Does anyone have any recommendations for good tools to perform
> file-system/tree backups and restores to/from a (Ceph RGW-based)
> object store (Swift or S3 APIs)? Happy to hear about both FOSS and
> commercial options please.
>
> I'm interested in:
> 1) tools known to work or not work at all for a basic file-based data backup
>
> Plus these extras:
> 2) preserves/restores correct file metadata (e.g. owner, group, acls etc)
> 3) preserves/restores xattrs
> 4) backs up empty directories and files
> 5) supports some sort of snapshot/versioning/differential
> functionality, i.e., will keep a copy or diff or last N versions of a
> file or whole backup set, e.g., so that one can restore yesterday's
> file/s or last week's but not have to keep two full copies to achieve
> it
> 6) is readily able to restore individual files
> 7) can encrypt/decrypt client side
> 8) anything else I should be considering?

I've used duplicity before and it seems to provide most of the
features you are looking for (not sure about xattrs though):

   http://duplicity.nongnu.org/

S3 and Swift are both supported.

There are also a bunch of duplicity frontends available; e.g. duply,
deja-dup, duplicati, etc.

Cheers,
Marcus.

-- 
Marcus Furlong

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

Re: [Openstack-operators] Please give your opinion about "openstack server migrate" command.

[Marcus Furlong]

On 17 February 2017 at 17:05, Marcus Furlong <furlo...@gmail.com> wrote:
> On 17 February 2017 at 16:47, Rikimaru Honjo
> <honjo.rikim...@po.ntts.co.jp> wrote:
>> Hi all,
>>
>> I found and reported a unkind behavior of "openstack server migrate" command
>> when I maintained my environment.[1]
>> But, I'm wondering which solution is better.
>> Do you have opinions about following my solutions by operating point of
>> view?
>> I will commit a patch according to your opinions if those are gotten.
>>
>> [1]https://bugs.launchpad.net/python-openstackclient/+bug/1662755
>> ---
>> [Actual]
>> If user run "openstack server migrate --block-migration ",
>> openstack client call Cold migration API.
>> "--block migration" option will be ignored if user don't specify "--live".
>>
>> But, IMO, this is unkindly.
>> This cause unexpected operation for operator.
>
> +1 This has confused/annoyed me before.

And having said that, the nova client itself also has some confusing
verbs which require explanation:

http://www.danplanet.com/blog/2016/03/03/evacuate-in-nova-one-command-to-confuse-us-all/

>>
>> P.S.
>> "--shared-migration" option has same issue.
>
> For the shared migration case, there is also this bug:
>
>https://bugs.launchpad.net/nova/+bug/1459782
>
> which, if fixed/implemented would negate the need for
> --shared-migration? And would fix also "nova resize" on shared
> storage.
>
> Cheers,
> Marcus.

-- 
Marcus Furlong

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

Re: [Openstack-operators] Please give your opinion about "openstack server migrate" command.

[Marcus Furlong]

On 17 February 2017 at 16:47, Rikimaru Honjo
 wrote:
> Hi all,
>
> I found and reported a unkind behavior of "openstack server migrate" command
> when I maintained my environment.[1]
> But, I'm wondering which solution is better.
> Do you have opinions about following my solutions by operating point of
> view?
> I will commit a patch according to your opinions if those are gotten.
>
> [1]https://bugs.launchpad.net/python-openstackclient/+bug/1662755
> ---
> [Actual]
> If user run "openstack server migrate --block-migration ",
> openstack client call Cold migration API.
> "--block migration" option will be ignored if user don't specify "--live".
>
> But, IMO, this is unkindly.
> This cause unexpected operation for operator.

+1 This has confused/annoyed me before.

>
> P.S.
> "--shared-migration" option has same issue.

For the shared migration case, there is also this bug:

   https://bugs.launchpad.net/nova/+bug/1459782

which, if fixed/implemented would negate the need for
--shared-migration? And would fix also "nova resize" on shared
storage.

Cheers,
Marcus.

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

Re: [Openstack-operators] heat-cfntools and heat SoftwareConfig

[Marcus Furlong]

On 5 December 2016 at 02:04, Ignazio Cassano <ignaziocass...@gmail.com> wrote:
> Hello,
> I often use heat templates with SoftwareConfig and it works fine if virtual
> machine images are built using disk-image-builder.
> I would like to know if it possible install on a clean image all tools
> needed by hand.
> I tryed with an ubuntu 16.04 : I installed the heat-cfntools package on it
> but vm from this image are not able to receive SoftwareConfig rules from
> heat.

Have you also installed the cloudinit package?

Cheers,
Marcus.

-- 
Marcus Furlong

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

Re: [Openstack-operators] Using novaclient, glanceclient, etc, from python

[Marcus Furlong]

API documentation is available here:

http://developer.openstack.org/api-guide/quick-start/

Cheers,
Marcus.

On 18 Nov 2016 05:21, "George Shuklin"  wrote:

> Hello.
>
> I can't find proper documentation about how to use openstack clients from
> inside python application. All I can find is just examples and rather
> abstract (autogenerated) reference. Is there any normal documentation about
> proper way to use openstack clients from python applications?
>
>
> 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] Missing network information on Newton?

[Marcus Furlong]

   |
98e5f72a-e8e6-48c3-bfc2-f6536307a431  |
| image| Ubuntu-16.04-x86_64
(53da5182-79b7-4b54-8997-82eabd6644bb)|
| key_name | furlongm
|
| metadata | {}
|
| name | test
|
| os-extended-volumes:volumes_attached | []
|
| progress | 0
|
| security_groups  | default
|
| status   | ACTIVE
|
| tenant_id|
723f40b70b8e4b06923c46a7cfc6de27  |
| updated  | 2016-08-09T06:09:56Z
|
| user_id  |
80811a40eef34725b3bcb3632f91c38a  |
| vxlan-test network   | 10.1.1.22, 180.148.27.214
|
+--+---+

Horizon shows both IP addresses correctly.

Has anyone else seen this? Is this the expected behaviour?

Cheers,
Marcus.
-- 
Marcus Furlong

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

Re: [Openstack-operators] Nova live-migration failing for RHEL7/CentOS7 VMs

[Marcus Furlong]

What's your qemu version, and what does the libvirt log on the destination
say?

You may have hit this bug:

https://bugzilla.redhat.com/show_bug.cgi?id=1371943

There are some workarounds listed there, and downgrading also fixes it.

Marcus.

On 29 Sep 2016 00:35, "William Josefsson" 
wrote:

> Hi,
>
> I have problems with nova live-migration for my CentOS7 and RHEL7 VMs.
> The live migrations works fine for Windows2012R2 and Ubuntu1404 VMs.
>
> For CentOS7/RHEL based images I get this error in the Destination node in
> nova-compute.log. Also console for logged in VM users on the VM freeze.
>
>
>
> 2016-09-28 10:49:24.101 353935 INFO nova.compute.manager [instance:
> cd0b605d] VM Resumed (Lifecycle Event)
> 2016-09-28 10:49:24.339 353935 INFO nova.compute.manager [instance:
> cd0b605d] VM Resumed (Lifecycle Event)
> 2016-09-28 10:49:25.866 353935 INFO nova.compute.manager [instance:
> cd0b605d] Post operation of migration started
> 2016-09-28 10:49:39.410 353935 INFO nova.compute.manager [instance:
> cd0b605d] VM Stopped (Lifecycle Event)
> *2016-09-28 10:49:39.532 353935 WARNING nova.compute.manager [instance:
> cd0b605d] Instance shutdown by itself. Calling the stop API. Current
> vm_state: active, current task_state: None, original DB power_state: 4,
> current VM power_state: 4*
> 2016-09-28 10:49:39.668 353935 INFO nova.compute.manager [instance:
> cd0b605d] Instance is already powered off in the hypervisor when stop is
> called.
> 2016-09-28 10:49:39.736 353935 INFO nova.virt.libvirt.driver [instance:
> cd0b605d] Instance already shutdown.
> 2016-09-28 10:49:39.743 353935 INFO nova.virt.libvirt.driver [instance:
> cd0b605d] Instance destroyed successfully.
>
>
> Eventually the VM ends up in SHUTDOWN state on the destination node.
>
> I'm on CentOS7/Liberty, and my storage backend is CEPH(Hammer 0.94.9).
>
> Please advice. thx will
>
> ___
> 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] nova resize on shared storage

[Marcus Furlong]

On 1 August 2016 at 14:02, Blair Bethwaite <blair.bethwa...@gmail.com> wrote:
> On 1 August 2016 at 13:30, Marcus Furlong <furlo...@gmail.com> wrote:
>> Looks like there is a bug open which suggests that it should be using
>> RPC calls, rather than commands executed over ssh:
>>
>> https://bugs.launchpad.net/nova/+bug/1459782
>
> I agree, no operator in their right mind wants to turn this on for a
> production cloud, but it's a capability that a lot of useful higher
> level tooling wants to exploit (e.g. right-sizing solutions). IIRC
> this was discussed some time ago and I thought there was something in
> the dev pipeline to address it. Looking at the bug it does mention the
> related live-migration cleanup work that happened ~Havana or so, I
> guess the cold-migrate/resize pathway was missed or did it get stuck
> in review?

Good question. CC:ing openstack-dev in the hope someone might know.

> On this point in the bug report:
> ==
> There's a complication though. In virt.libvirt.utils.copy_image() we
> also rely on passwordless authentication to do either "rsync" or "scp"
> to copy the image file over when doing cold migration with local
> storage. So for the case of local storage we'd still need to set up
> passwordless ssh between compute nodes to handle cold migration.
> ==
>
> Passwordless ssh for services need not be so scary, it just needs to
> be managed right... Fortunately OpenSSH has a rather cool feature
> (that lots of people seem not to know about) - it supports auth by
> certificate, by which I mean an appropriately configured sshd can
> authenticate a client's cert based on the fact that it was signed by a
> trusted SSH CA without any need to have a record of the client's
> public key. Signed certs are valid for a limited time, so you can
> imagine building some automation that created a short-lived cert on
> demand that was valid just long enough to establish the scp connection
> needed to complete a cold-migration or resize. See "man ssh-keygen" ->
> CERTIFICATES.

Would it also be possible to use glance to store the image for the
local storage scenario? That would remove the ssh access requirement
from the equation completely.  Upload from source, download to
destination, then delete?
-- 
Marcus Furlong

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

Re: [Openstack-operators] nova resize on shared storage

[Marcus Furlong]

On 28 July 2016 at 18:53, Matteo Panella <matteo.pane...@cnaf.infn.it> wrote:
> Hi,
>
> On 28/07/2016 10:34, Marcus Furlong wrote:
>> I've been trying to find some information about using nova resize on
>> shared storage, without giving each compute node ssh access to every
>> other compute node. As the VM is on shared storage, the compute node
>> shouldn't need ssh access to another compute node?
>
> AFAIR, nova-compute uses ssh to check whether the source and target
> compute node are in fact sharing the underlying storage for resize (and
> migrate) operations so it can choose the best resize strategy (scp
> versus local copy).
>
>> Is this something that anyone has succeeded in doing?
>
> Yep, we have GPFS as our underlying shared filesystem and we had to
> setup cross-node ssh access for nova in order to get resize/migration
> working (live migration is another story: if you're using ssh-tunneled
> connections you're already set).
>
>> I've found the following documentation:
>>
>>http://docs.openstack.org/mitaka/config-reference/compute/resize.html
>>
>> http://docs.openstack.org/user-guide/cli_change_the_size_of_your_server.html
>>
>> but it does not say what to do in the case of shared storage.
>
> You should do the same thing for non-shared storage: set up ssh access
> for nova across all compute nodes. nova-compute will recognize that the
> underlying storage is shared and bypass ssh for all image-related
> operations.

I'd like to avoid giving each compute node ssh access to every other
compute node, for security reasons. If one node is compromised, 1000
nodes are compromised, which is not good. The compute nodes have no
other reason to have ssh access to each other.

Looks like there is a bug open which suggests that it should be using
RPC calls, rather than commands executed over ssh:

https://bugs.launchpad.net/nova/+bug/1459782

Cheers,
Marcus.

-- 
Marcus Furlong

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

[Openstack-operators] nova resize on shared storage

[Marcus Furlong]

Hi,

I've been trying to find some information about using nova resize on
shared storage, without giving each compute node ssh access to every
other compute node. As the VM is on shared storage, the compute node
shouldn't need ssh access to another compute node?

Is this something that anyone has succeeded in doing?

I've found the following documentation:

   http://docs.openstack.org/mitaka/config-reference/compute/resize.html
   http://docs.openstack.org/user-guide/cli_change_the_size_of_your_server.html

but it does not say what to do in the case of shared storage.

Cheers,
Marcus.
-- 
Marcus Furlong

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

Re: [Openstack-operators] [neutron] router Found my bug Can't add gateway

[Marcus Furlong]

On 26 March 2016 at 21:14, Christopher Hull <chrishul...@gmail.com> wrote:
> Hi Keven;
>
> "Bug fixed a long time ago.   How do you have old Nuetron version?"
>
> I was wondering that myself.   See the install guide
> http://docs.openstack.org/liberty/install-guide-rdo/environment-packages.html
>
> Indeed my Neutron (and likely other parts of my install) seem quite old.
> How can this be?
>
> The fix is in neutron 7.0.2.
> [root@maersk qr]# neutron --version
> 3.1.0   ???   wow!

That's the python-neutronclient version, not the released neutron version:

https://pypi.python.org/pypi/python-neutronclient/3.1.0

vs

http://releases.openstack.org/liberty/index.html

Not sure where client <-> openstack release relationship is documented though.

It should be easy enough to check the code on the machine in question
to ensure the patch you referred to has been applied.

Cheers,
Marcus.
-- 
Marcus Furlong

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

Re: [Openstack-operators] What are you excited for in Mitaka?

[Marcus Furlong]

On 10 March 2016 at 16:33, Matt Kassawara <mkassaw...@gmail.com> wrote:
> Don't forget about fixing MTU in neutron. No more confusing options that
> don't really do anything.

Does this mean we can modify the MTU via the API now?

-- 
Marcus Furlong

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

[Openstack-operators] kilo keystone with liberty nova

[Marcus Furlong]

Hi,

Just wanted to check if it's possible to have a mixed version
environment with kilo keystone and e.g. liberty nova.

Has anyone done this? Any gotchas?

Regards,
Marcus.
-- 
Marcus Furlong

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

Re: [Openstack-operators] How to restrict AvZones to Tenants

[Marcus Furlong]

On 27 August 2015 at 06:48, raju raju.r...@gmail.com wrote:
 Hi,

 I want to restrict Avzones to particular Tenant so that users in the Tenant
 can only see the particular Avzone from drop down while provisioning
 instances.

Hi Raju,

I don't think it's possible at the moment, however there is currently
a review in progress that will hopefully implement quotas per AZ:

   https://review.openstack.org/#/c/206160/

Regards,
Marcus.
-- 
Marcus Furlong

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