Re: [Openstack-operators] [dnsmasq] setting ntp-server

[Carlos Konstanski]

tldr; you have to use an IP address, not a DNS name, in the ntp-server
config.

In dhcp_agent.ini:

dnsmasq_config_file = /etc/neutron/dnsmasq.conf

In /etc/neutron/dnsmasq.conf:

dhcp-option=option:ntp-server,

I was trying to use a  instead of an  . The result
was that the floating IP was not being wired correctly. Packets were not
making it to the qr device. Not sure why.

But with an IP address, everything works and a
/var/lib/ntp/ntp.conf.dhcp gets written. As long as the /etc/init.d/ntp
script looks for this file, everything is golden.

Carlos

Carlos Konstanski <ckonstan...@pippiandcarlos.com> writes:

> I am searching for a way to set NTP servers in instances. Thre are at
> least two ways to do this that come to mind: DHCP and cloud.cfg. I would
> like to explore DHCP for this discussion.
>
> dnsmasq supports the following configuration:
>
> dhcp-option=option:ntp-server,,,...
>
> In the Ubuntu /etc/init.d/ntp service script the following can be found:
>
> if [ /var/lib/ntp/ntp.conf.dhcp -nt /etc/ntp.conf ]; then
> NTPD_OPTS="$NTPD_OPTS -c /var/lib/ntp/ntp.conf.dhcp"
> fi
>
> It would seem that the two work together to allow DHCP to override
> /etc/ntp.conf.
>
> The question is how to get openstack to configure dnsmasq thusly. There
> are two possibilities: a neutron config option or the overriding of the
> entire dnsmasq.conf. The former would be mch simpler and less messy. Is
> there such a setting in neutron.conf?
>
> Carlos Konstanski
>
> ___
> 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] [dnsmasq] setting ntp-server

[Carlos Konstanski]

I am searching for a way to set NTP servers in instances. Thre are at
least two ways to do this that come to mind: DHCP and cloud.cfg. I would
like to explore DHCP for this discussion.

dnsmasq supports the following configuration:

dhcp-option=option:ntp-server,,,...

In the Ubuntu /etc/init.d/ntp service script the following can be found:

if [ /var/lib/ntp/ntp.conf.dhcp -nt /etc/ntp.conf ]; then
NTPD_OPTS="$NTPD_OPTS -c /var/lib/ntp/ntp.conf.dhcp"
fi

It would seem that the two work together to allow DHCP to override
/etc/ntp.conf.

The question is how to get openstack to configure dnsmasq thusly. There
are two possibilities: a neutron config option or the overriding of the
entire dnsmasq.conf. The former would be mch simpler and less messy. Is
there such a setting in neutron.conf?

Carlos Konstanski

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

[Openstack-operators] [nova] Obtaining nova settings at runtime

[Carlos Konstanski]

Is there a way to obtain nova configuration settings at runtime without
resorting to SSHing onto the compute host and greping nova.conf? For
instance a CLI call? At the moment I'm looking at cpu_allocation_ratio
and ram_allocation_ratio. There may be more along this vein.

Alles Gute,
Carlos Konstanski

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

Re: [Openstack-operators] [nova] instance partition size discrepancy

[Carlos Konstanski]

I'll check the image for these tools. I should have mentioned that the
behavior is intermittent. Sometimes it does the right thing.

At first I thought I could choose "manual" partitioning when creating
the instance. But that turned out to have no effect. It worked the first
time, but I think it was just a coincidence. In reality, about one in
every three instance creations works and the other two don't.

Next time I reproduce the issue I will try resize2fs. Thanks for that.

Carlos

Tomáš Vondra <von...@homeatcloud.cz> writes:

> Have you tried
> # resize2fs /dev/vda
> ?
> Alternatively, if you use images with cloud-init and
> initramfs-growroot installed, it should work out of the box.
> Tomas
>
> -----Original Message-
> From: Carlos Konstanski [mailto:ckonstan...@pippiandcarlos.com] 
> Sent: Wednesday, April 26, 2017 12:02 AM
> To: openstack-operators@lists.openstack.org
> Subject: [Openstack-operators] [nova] instance partition size discrepancy
>
> I'm having an issue where the instance thinks its root filesystem is
> much smaller than the size of the volume that I used to create it. Not
> only that, the OS cannot decide on whether it thinks the size is right
> or wrong.
>
> See the following pastebin:
> https://paste.pound-python.org/show/eNt8nLNLhHAL5OYICqbs/
>
> Notice that everything shows the size as 20 GB except df, which shows
> it as 2.8 GB. I ran the previous instance out of space before spinning
> up this new one, so 2.8 seems to be the winner (though wrong).
>
> Figured I'd check to see if this is a known issue while I dig deeper.
>
> Carlos Konstanski
>
> ___
> 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] [openstack-operators] [nova] cloud.cfg not applied

[Carlos Konstanski]

Good idea. I just tried again with the "shebang". Didn't help. But I
will be sure to include it in the future at all times.

"Edmund Rhudy (BLOOMBERG/ 120 PARK)" <erh...@bloomberg.net> writes:

> Are you starting the file with "#cloud-config"? AFAIK, cloud-init uses
> the first line to decide how to process the file (e.g. if it starts
> with a shell shebang it will treat it as a shell script, #cloud-config
> will cause it to process it as cloud-init YAML, and so forth). I am
> not sure if it will try to process the file using a default mechanism
> if none is specified, but you could try specifying it explicitly to
> see if that causes cloud-init to process the user data.
>
> From: ckonstan...@pippiandcarlos.com 
> Subject: Re: [Openstack-operators] [openstack-operators] [nova] cloud.cfg not 
> applied
>
> It does look funny at first. But that's actually two separate
> users. This cloud.cfg has been verified in an enterprise cloud. Apart
> from the passwd stuff (which I will remove) I am certain it should
> work. It specifies that the default user should be created as normal,
> and it adds a second ckonstanski user with sudo, ssh-key, etc.
>
> m foster <mfost...@gmail.com> writes:
>
>> The only thing I can think of is that the default user should just be
>> "default", not qualified with "name". Perhaps that is clobbering your next
>> entry or just creating a syntax error.
>>
>> On Wed, Apr 12, 2017 at 11:34 AM, Carlos Konstanski <
>> ckonstan...@pippiandcarlos.com> wrote:
>>
>>> I cannot get a simple cloud.cfg to be applied to a newly created
>>> instance. This is the cloud.cfg: (sensitive info removed)
>>>
>>> users:
>>>   - name: default
>>>   - name: ckonstanski
>>> groups: sudo
>>> shell: /bin/bash
>>> sudo: ['ALL=(ALL) NOPASSWD:ALL']
>>> passwd: 
>>> lock_passwd: False
>>> ssh-authorized-keys:
>>>   - ssh-rsa 
>>>
>>>
>>> I'm not usually in the habit of setting passwords, but I had hoped that
>>> perhaps it only the SSH pubkey part that wasn't working. Turns out none
>>> of it works, the user isn't created at all.
>>>
>>> I tried with a variety of OS images: gentoo, ubuntu 14.04, ubuntu 16.04,
>>> centos 7. I downloaded official cloud images for all of these.
>>>
>>> If I shell onto the instances and run:
>>>
>>> curl http://169.254.169.254/2009-04-04/user-data
>>>
>>> the cloud.cfg is returned.
>>>
>>> I built this openstack according to the official newton install guide.
>>>
>>> Looking for ways to troubleshoot this. What is the mechanism that gets
>>> the cloud.cfg applied? Any info would be helpful, even a link.
>>>
>>> Sincerely,
>>>
>>> Carlos Konstanski
>>>
>>> ___
>>> 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] [openstack-operators] [nova] cloud.cfg not applied

[Carlos Konstanski]

It does look funny at first. But that's actually two separate
users. This cloud.cfg has been verified in an enterprise cloud. Apart
from the passwd stuff (which I will remove) I am certain it should
work. It specifies that the default user should be created as normal,
and it adds a second ckonstanski user with sudo, ssh-key, etc.

m foster <mfost...@gmail.com> writes:

> The only thing I can think of is that the default user should just be
> "default", not qualified with "name". Perhaps that is clobbering your next
> entry or just creating a syntax error.
>
> On Wed, Apr 12, 2017 at 11:34 AM, Carlos Konstanski <
> ckonstan...@pippiandcarlos.com> wrote:
>
>> I cannot get a simple cloud.cfg to be applied to a newly created
>> instance. This is the cloud.cfg: (sensitive info removed)
>>
>> users:
>>   - name: default
>>   - name: ckonstanski
>> groups: sudo
>> shell: /bin/bash
>> sudo: ['ALL=(ALL) NOPASSWD:ALL']
>> passwd: 
>> lock_passwd: False
>> ssh-authorized-keys:
>>   - ssh-rsa 
>>
>>
>> I'm not usually in the habit of setting passwords, but I had hoped that
>> perhaps it only the SSH pubkey part that wasn't working. Turns out none
>> of it works, the user isn't created at all.
>>
>> I tried with a variety of OS images: gentoo, ubuntu 14.04, ubuntu 16.04,
>> centos 7. I downloaded official cloud images for all of these.
>>
>> If I shell onto the instances and run:
>>
>> curl http://169.254.169.254/2009-04-04/user-data
>>
>> the cloud.cfg is returned.
>>
>> I built this openstack according to the official newton install guide.
>>
>> Looking for ways to troubleshoot this. What is the mechanism that gets
>> the cloud.cfg applied? Any info would be helpful, even a link.
>>
>> Sincerely,
>>
>> Carlos Konstanski
>>
>> ___
>> 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] [openstack-operators] [nova] cloud.cfg not applied

[Carlos Konstanski]

I cannot get a simple cloud.cfg to be applied to a newly created
instance. This is the cloud.cfg: (sensitive info removed)

users:
  - name: default
  - name: ckonstanski
groups: sudo
shell: /bin/bash
sudo: ['ALL=(ALL) NOPASSWD:ALL']
passwd: 
lock_passwd: False
ssh-authorized-keys:
  - ssh-rsa 


I'm not usually in the habit of setting passwords, but I had hoped that
perhaps it only the SSH pubkey part that wasn't working. Turns out none
of it works, the user isn't created at all.

I tried with a variety of OS images: gentoo, ubuntu 14.04, ubuntu 16.04,
centos 7. I downloaded official cloud images for all of these.

If I shell onto the instances and run:

curl http://169.254.169.254/2009-04-04/user-data

the cloud.cfg is returned.

I built this openstack according to the official newton install guide.

Looking for ways to troubleshoot this. What is the mechanism that gets
the cloud.cfg applied? Any info would be helpful, even a link.

Sincerely,

Carlos Konstanski

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

Re: [Openstack-operators] Glance image 'visibility' migration in Ocata

[Carlos Konstanski]

- There seems to be no difference between public and community, and the
  README does not do an adequate job of explaining the difference.

- There is nothing conceptually wrong with having something be private
  and letting it have a list of members. Private does not have to mean
  "just one user". I can be a member of a private club for example. That
  does not mean I sit there and drink all alone. Shared seems
  redundant. We can't trust users to manage the members list if they
  really want something to be super-duper-private?

Just my 2 cents and a first impression of these proposed changes. I
don't want to comment in the review until I'm clear on the purpose of
these changes, which at the moment is not clear. Everything that could
be done with these changes can be done now, just with different names.

Brian Rosmaita  writes:

> Hello Operators,
>
> As you may be aware, the discussion about image 'visibility' and its
> migration carried on into 2017 and was only recently settled.  I'm
> writing this because the direction we ultimately took (after much
> discussion--did I mention that?) was *not* the recommendation I made in
> the email below.  I just want to point that out in case the email below
> was last news you'd heard about this issue.
>
> So what actually *did* happen?  There's a patch up for the release note
> explaining the visibility changes in Ocata.  As we'd like it to be
> completely clear, I'd appreciate it if you'd take a few minutes to read
> through it and leave comments on the patch.  Please point out if there's
> anything expressed ambiguously, or if there are any questions that come
> to mind that aren't addressed in the release notes.
>
> https://review.openstack.org/#/c/422897/
>
> thanks,
> brian
>
> On 12/2/16 5:33 PM, Brian Rosmaita wrote:
>> Hello Operators,
>> 
>> Here are the results of the recent operators' poll concerning the
>> upcoming image visibility changes in Glance and the direction we plan to
>> take.  Thanks to all participants for helping us come to a data-driven
>> decision on a contentious issue.
>> 
>> (For background on the operators' poll, see [0].)
>> 
>> The operators' poll was taken to determine the migration strategy:
>> (A) All pre-Ocata 'private' images are migrated to 'shared'.
>> (B) 'private' images with no members stay 'private', 'private' images
>> with members are migrated to 'shared'.
>> (C) No strong preference as long as the documentation is clear.
>> 
>> The results were inconclusive:
>> 9 total responses: 4 for (A), 4 for (B), 1 for (C)
>> 
>> I recommend that we go with option (A).  Here's why (in addition to the
>> arguments made in [2], and my arguments in the "outside" comments on [2]):
>> 
>> (1) There was a comment on the poll that 'private' creates an
>> expectation that we should meet.  This is basically my reason for
>> rejecting Hemanth's otherwise sensible comment on the patch that we
>> should remove 'shared' visibility from Timothy's patch [1] and deal with
>> the issue later.  This is a problem we should deal with now.
>> 
>> (2) We want to respect the principle of least surprise for users, in
>> other words, changes in API behavior as a consequence of changes
>> introduced in Timothy's community/shared images patch [1] are OK if
>> they're a result of something a user *does*, but not OK if they are
>> something that *happens to* a user.  To make this point concrete: if a
>> current image with no members is made 'private' during migration,
>> suddenly the add-member call can't be made on that image in either the
>> v1 or v2 API.  If the image is migrated to 'shared', on the other hand,
>> the current user workflow is not changed.  If the user decides to set
>> the visibility on the image to 'private', then the add-member calls will
>> return 409s, but that's OK because it's a result of an action the user took.
>> 
>> But, you say, all my previously 'private' images being listed as
>> 'shared' could be a big surprise!  I think this is a trade-off we should
>> accept, and address by educating Ocata operators and users of what to
>> expect.  Here's the key thing people need to be aware of:
>> 
>> You can specify a visibility of 'private' at the time of image creation,
>> and it's respected.  An interface could (should?) make this choice clear
>> at the time of image creation.
>> 
>> So to be completely clear, my recommendation is that we go with
>> migration strategy (A) (i.e., the one specified in [2]) and Timothy's
>> current community/shared images patch [1].
>> 
>> What's missing in Glance is an easy way to list images that have
>> visibility 'shared' and no members (and hence, aren't consumable by
>> anyone other than the owner) from images with visibility 'shared' that
>> do have members.  This could be addressed by adding a 'has_members'
>> field to the Image object.  We could use some feedback on how useful
>> such a field would be.
>> 
>> This course of action is a compromise so that we can