Open Stack

> I took a glance on Maciej's patch and it adds a switch to tar command
> to make it follow symbolic links

Yeah, that should work. Except one thing - we previously had fqdn ->
ipaddr links in snapshots. So now they will be resolved into full
copy?

> I meant that symlinks also give us the benefit of not using additional
> space (just as hardlinks do) while being able to link to files from
> different filesystems.

I'm sorry, I got you wrong. :)

- Igor

On Thu, Jan 14, 2016 at 12:34 PM, Maciej Kwiek <mkwiek at mirantis.com> wrote:
> Igor,
>
> I meant that symlinks also give us the benefit of not using additional space
> (just as hardlinks do) while being able to link to files from different
> filesystems.
>
> Also, as Barłomiej pointed out the `h` switch for tar should do the trick
> [1].
>
> Cheers,
> Maciej
>
> [1] http://www.gnu.org/software/tar/manual/html_node/dereference.html
>
> On Thu, Jan 14, 2016 at 11:22 AM, Bartlomiej Piotrowski
> <bpiotrowski at mirantis.com> wrote:
>>
>> Igor,
>>
>> I took a glance on Maciej's patch and it adds a switch to tar command to
>> make it follow symbolic links, so it looks good to me.
>>
>> Bartłomiej
>>
>> On Thu, Jan 14, 2016 at 10:39 AM, Igor Kalnitsky <ikalnitsky at mirantis.com>
>> wrote:
>>>
>>> Hey Maceij -
>>>
>>> > About hardlinks - wouldn't it be better to use symlinks?
>>> > This way we don't occupy more space than necessary
>>>
>>> AFAIK, hardlinks won't occupy much space. They are the links, after all.
>>> :)
>>>
>>> As for symlinks, I'm afraid shotgun (and fabric underneath) won't
>>> resolve them and links are get to snapshot As Is. That means if there
>>> will be no content in the snapshot they are pointing to, they are
>>> simply useless. Needs to be checked, though.
>>>
>>> - Igor
>>>
>>> On Thu, Jan 14, 2016 at 10:31 AM, Maciej Kwiek <mkwiek at mirantis.com>
>>> wrote:
>>> > Thanks for your insight guys!
>>> >
>>> > I agree with Oleg, I will see what I can do to make this work this way.
>>> >
>>> > About hardlinks - wouldn't it be better to use symlinks? This way we
>>> > don't
>>> > occupy more space than necessary, and we can link to files and
>>> > directories
>>> > that are in other block device than /var. Please see [1] review for a
>>> > proposed change that introduces symlinks.
>>> >
>>> > This doesn't really give us much right now, because most of the logs
>>> > are
>>> > fetched from master node via ssh due to shotgun being run in
>>> > mcollective
>>> > container, but it's something! When we remove containers, this will
>>> > prove
>>> > more useful.
>>> >
>>> > Regards,
>>> > Maciej Kwiek
>>> >
>>> > [1] https://review.openstack.org/#/c/266964/
>>> >
>>> > On Tue, Jan 12, 2016 at 1:51 PM, Oleg Gelbukh <ogelbukh at mirantis.com>
>>> > wrote:
>>> >>
>>> >> I think we need to find a way to:
>>> >>
>>> >> 1) verify the size of snapshot without actually making it and compare
>>> >> to
>>> >> the available disk space beforehand.
>>> >> 2) refuse to create snapshot if space is insufficient and notify user
>>> >> (otherwise it breaks Admin node as we have seen)
>>> >> 3) provide a way to prioritize elements of the snapshot and exclude
>>> >> them
>>> >> based on the priorities or user choice.
>>> >>
>>> >> This will allow for better and safer UX with the snapshot.
>>> >>
>>> >> --
>>> >> Best regards,
>>> >> Oleg Gelbukh
>>> >>
>>> >> On Tue, Jan 12, 2016 at 1:47 PM, Maciej Kwiek <mkwiek at mirantis.com>
>>> >> wrote:
>>> >>>
>>> >>> Hi!
>>> >>>
>>> >>> I need some advice on how to tackle this issue. There is a bug [1]
>>> >>> describing the problem with creating a diagnostic snapshot. The issue
>>> >>> is
>>> >>> that /var/log has 100GB available, while /var (where diagnostic
>>> >>> snapshot is
>>> >>> being generated - /var/www/nailgun/dump/fuel-snapshot according to
>>> >>> [2]) has
>>> >>> 10GB available, so dumping the logs can be an issue when logs size
>>> >>> exceed
>>> >>> free space in /var.
>>> >>>
>>> >>> There are several things we could do, but I am unsure on which course
>>> >>> to
>>> >>> take. Should we
>>> >>> a) Allocate more disk space for /var/www (or for whole /var)?
>>> >>> b) Make the snapshot location share the diskspace of /var/log?
>>> >>> c) Something else? What?
>>> >>>
>>> >>> Please share your thoughts on this.
>>> >>>
>>> >>> Cheers,
>>> >>> Maciej Kwiek
>>> >>>
>>> >>> [1] https://bugs.launchpad.net/fuel/+bug/1529182
>>> >>> [2]
>>> >>>
>>> >>> https://github.com/openstack/fuel-web/blob/2855a9ba925c146b4802ab3cd2185f1dce2d8a6a/nailgun/nailgun/settings.yaml#L717
>>> >>>
>>> >>>
>>> >>>
>>> >>> __________________________________________________________________________
>>> >>> 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.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.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.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.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.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>