Yes, I agree with that. Especially, the detail information of images would
be very useful for qcow2 images due to the lack of metadata information.
And it would be helpful for migration. Thank you.
Best regards,
Young
On Wed, Jul 30, 2014 at 6:23 PM, Curtis wrote:
> Hi all,
>
> We found out t
Hi all,
We found out today that windows images in openstack should have the
glance os_type set to windows:
http://docs.openstack.org/image-guide/content/windows-image.html
So might not be a bad idea for the vcl openstack plugin to add that
metadata if the image being created is a windows os.
Th
Then option 2 sounds reasonable. Just warn and log if openstack gets
failed to delete the instance but continue to load a new instance. It seems
okay to me.
Best regards,
Young
On Wed, Jul 23, 2014 at 12:38 PM, Cameron Mann
wrote:
> The new instance that gets created is completely independent
The new instance that gets created is completely independent from the old
one; both could remain powered on with no problems. OpenStack handles the
IP addresses and if one is already in use it won't be assigned again. Just
in case there's any confusion, the issue before was that the module was
usin
Option 2 sounds reasonable as long as there is no possibility the VM which
could not be deleted can not cause conflicts with other VMs. The main
concern would be if the VM remained powered on with an IP address that
could be reused. Would this be possible? If you encounter a problem
deleting a V
I think a variant of option 2 is ideal, similar to the vmware module.
Warn and log if it does not get deleted and only fail the vm node if
it still responds to ssh.
Also could extend the healthcheck module to do routine cleanup.
just my thoughts,
Aaron
On Tue, Jul 22, 2014 at 3:37 PM, Cameron
Agreed, this goes back to more general VCL behaviour so it would be good to
get others' input.
Cameron
On Tue, Jul 22, 2014 at 1:22 PM, YOUNG OH wrote:
> That's great observation. I think option 1 and 2 can provide fast loading
> time due to no load failure. But, to avoid quota issues, an admi
That's great observation. I think option 1 and 2 can provide fast loading
time due to no load failure. But, to avoid quota issues, an admin should
periodically check the all the instances whether there are any duplicate
instance names and defunct instances. The option 3 is safe but slow to load
if
Looks good. Though I do wonder if it's necessary to fail the entire load
process just because the old instance doesn't get deleted. I think there's
three possibilities:
1. Don't check for successful deletion; there won't be any conflicts
because we're using openstackComputerMap. This would give th
Cameron,
Yes, you are definitely right. I was noticed that using hostname to find
the openstack instance id is not working properly and also can cause the
problem you described. I've back to use the openstackComputerMap table to
get_os_instance_id when the instance is pingable and also add a loop
Sounds like good progress to me. One comment though, it looks like
_terminate_os_instance does the DELETE request, checks the response for
success and then sleeps for 30 seconds while the instance deletes. However,
I don't believe a successful response to the DELETE request guarantees the
instance
Cameron,
I hope you had a great time and welcome back to work :-). And, yes, the
OpenStack module with directly using OpenStack APIs can solve the concerns
we've discussed and it's more flexible to apply new version of OpenStack
APIs, if necessary. In the updated openstack module, I've changed the
Sorry for the silence from my end, I realized I forgot to mention I was
going to be on vacation for the last week and a half. Anyways, it looks
like Young's updates have addressed the main concerns we were having with
regards to the command line client. Given the progress he's made we think
going a
Andy,
Thank you for your comments. I've tried to apply what you addressed and
committed my module again. This module finds all openstack information
using OpenStack APIs and database. Thank you.
Best regards,
Young-Hyun
On Wed, Jul 9, 2014 at 10:24 AM, Andy Kurth wrote:
> Thanks Young. Look
Thanks Young. Looks good! If I understand correctly, you are avoiding the
need to use the CLI or cpan module by interacting directly with OpenStack
via the REST API?
It looks like the only commands you're running on the management node are
"nova" and "qemu-img" in _get_flavor_type. Would it be
Original Message-
>> From: Cameron Mann [mailto:[email protected]]
>> Sent: Monday, June 30, 2014 3:13 PM
>> To: [email protected]
>> Subject: Re: OpenStack Module
>>
>> Chris,
>>
>> Do you (or anyone else for that matter) know if there ar
back to you.
>
> Regards,
> Chris
>
> -Original Message-
> From: Cameron Mann [mailto:[email protected]]
> Sent: Monday, June 30, 2014 3:13 PM
> To: [email protected]
> Subject: Re: OpenStack Module
>
> Chris,
>
> Do you (or anyone else for that m
. I'll try and assess the current
state of JSON output compliance and get back to you.
Regards,
Chris
-Original Message-
From: Cameron Mann [mailto:[email protected]]
Sent: Monday, June 30, 2014 3:13 PM
To: [email protected]
Subject: Re: OpenStack Module
Chris,
Do you (or
.
>
> Regards,
> Chris
>
>
> -Original Message-----
> From: Cameron Mann [mailto:[email protected]]
> Sent: Wednesday, June 25, 2014 2:38 PM
> To: [email protected]
> Subject: Re: OpenStack Module
>
> Hi all,
>
> We had a call earlier today to discu
essage-
From: Cameron Mann [mailto:[email protected]]
Sent: Wednesday, June 25, 2014 2:38 PM
To: [email protected]
Subject: Re: OpenStack Module
Hi all,
We had a call earlier today to discuss which OpenStack module we should focus
our development efforts on and at this point a community decision is r
Hi all,
We had a call earlier today to discuss which OpenStack module we should
focus our development efforts on and at this point a community decision is
required. For reference, Young Oh's module is available in trunk and ours
is on GitHub (https://github.com/cybera/openstack-vcl-module). Our mo
I think we're all in agreement that removing dependencies on /etc/hosts is
an improvement. I'm working on this and should have the changes committed
this week.
To summarize the situation and changes, the backend code currently reads
/etc/hosts in order to determine the private IP address of a nod
dnsmasq protocol is for OpenStack. We might need to find another way to
solve this problem.
Thanks,
Young-Hyun
On Wed, Jun 4, 2014 at 1:55 PM, Curtis wrote:
> On Wed, Jun 4, 2014 at 11:49 AM, YOUNG OH wrote:
> > Hi Curtis,
> >
> > I think you can change the default lease time for dnsmasq pr
On Wed, Jun 4, 2014 at 11:49 AM, YOUNG OH wrote:
> Hi Curtis,
>
> I think you can change the default lease time for dnsmasq protocol in
> /etc/dnsmasq.conf. It seems the default dhcp lease time is 150 (150 seconds
> I guess).
Where are you suggesting changing it? We can't change it in OpenStack
b
Hi Curtis,
I think you can change the default lease time for dnsmasq protocol in
/etc/dnsmasq.conf. It seems the default dhcp lease time is 150 (150 seconds
I guess).
Thanks,
Young-Hyun
On Wed, Jun 4, 2014 at 11:52 AM, Curtis wrote:
> Also, as another note/issue, in openstack the dhcp time
Also, as another note/issue, in openstack the dhcp times are usually
set to a minute or two, which I find quite low but that is what it is
by default. For windows, during the provisioning process VCL sets the
time which causes the dhcp ticket to time out and the instance is left
without an IP and r
It was Andy's idea :)
Aaron
On Tue, Jun 3, 2014 at 4:19 PM, YOUNG OH wrote:
> I think so too.
>
> Young-Hyun
>
>
> On Tue, Jun 3, 2014 at 3:58 PM, Curtis wrote:
>
>> On Tue, Jun 3, 2014 at 1:52 PM, Aaron Peeler
>> wrote:
>> > Would using the private IP instead of hostnames resolve it? It would
I think so too.
Young-Hyun
On Tue, Jun 3, 2014 at 3:58 PM, Curtis wrote:
> On Tue, Jun 3, 2014 at 1:52 PM, Aaron Peeler
> wrote:
> > Would using the private IP instead of hostnames resolve it? It would
> > take a bit of work, but could be done.
>
> Yup that would work...as far as I can tell.
On Tue, Jun 3, 2014 at 1:52 PM, Aaron Peeler wrote:
> Would using the private IP instead of hostnames resolve it? It would
> take a bit of work, but could be done.
Yup that would work...as far as I can tell. :)
Thanks,
Curtis.
>
> Aaron
>
>
>
> On Tue, Jun 3, 2014 at 3:22 PM, Curtis wrote:
>>
Would using the private IP instead of hostnames resolve it? It would
take a bit of work, but could be done.
Aaron
On Tue, Jun 3, 2014 at 3:22 PM, Curtis wrote:
> On Tue, Jun 3, 2014 at 11:53 AM, YOUNG OH wrote:
>> Hi Curtis,
>>
>> Thank you for updating the status and correction about the Ope
On Tue, Jun 3, 2014 at 11:53 AM, YOUNG OH wrote:
> Hi Curtis,
>
> Thank you for updating the status and correction about the OpenStack Perl
> SDKs.
>
> If DNS lookup is not reliable to find the private ip of an instance for a
> multi-host openstack environment, then do you have any suggestion to d
Hi Curtis,
Thank you for updating the status and correction about the OpenStack Perl
SDKs.
If DNS lookup is not reliable to find the private ip of an instance for a
multi-host openstack environment, then do you have any suggestion to deal
with this issue?
At this point, I think at least we have
On Mon, Jun 2, 2014 at 12:45 PM, YOUNG OH wrote:
> Hi All,
>
> I would like to bring your attention again to discuss what OpenStack module
> should include. I would like to discus two issues first.
>
> First, we know that using /etc/hosts to get the private ip of an instance
> can be problematic.
Hi All,
I would like to bring your attention again to discuss what OpenStack module
should include. I would like to discus two issues first.
First, we know that using /etc/hosts to get the private ip of an instance
can be problematic. Specifically, Cameron (at Cybera) and I had found that
there m
Hi All,
I have tested my openstack module (
https://issues.apache.org/jira/browse/VCL-590) on the OpenStack Icehouse
(The ninth release of OpenStack, April 17, 2014) and I could provisioning a
Linux image through it.
The environment details are as follows:
1. Host Blade
:- CPU: Intel(R) Xeon(R)
>
> I haven't looked at Try::Tiny or any newer exception handling features of
> Perl, but I'd prefer to keep the number of external modules to a minimum if
> possible. If there are new features in Perl which would be beneficial, I'd
> rather make the newer version of Perl a requirement and use the
>
>
> 2. We use the Try::Tiny module to handle exceptions since the version of
> Perl VCL 2.3 uses doesn't support the saner try/catch mechanisms available
> in newer releases, however this would add an additional dependency to VCL.
> Depending on the version of Perl VCL 2.4 is planning to use what
Hi All --
One other thing I wanted to mention, fairly minor, is that OpenStack has
flavors for instances, which for VCL mostly means virtual CPUs and memory
given to a virtual machine. Right now, at Cybera, we just have a default
flavor, and then an optional flavor in the openstack image map datab
Hi Cameron,
Thanks for provided details of the modifications you added in to make
the module work at your site. I don't see any issues with what you
mentioned. Number 3 isn't really a major issue and the VCL core code
can be modified to not use the /etc/hosts file for the openstack
provisioning m
Date: 09/24/2013 07:28 AM
Subject: Re: OpenStack module and private IP addresses
Does the OpenStack module support Quantum or just Nova?
Mark
On Mon, Sep 23, 2013 at 7:48 PM, Young h Oh wrote:
> Cameron,
>
> Not at all. You just reminded me right time about this issue. I wil
I apologize for being
>
>
> From: Cameron Mann
> To: [email protected],
> Date: 09/23/2013 01:44 PM
> Subject: Re: OpenStack module and private IP addresses
> --
>
>
>
> Thanks for the reply. I didn't realize Curtis had already brought this
update my
progress soon. Thank you.
Best regards,
Young Hyun Oh
From: Cameron Mann
To: [email protected],
Date: 09/23/2013 01:44 PM
Subject:Re: OpenStack module and private IP addresses
Thanks for the reply. I
Thanks for the reply. I didn't realize Curtis had already brought this up,
so I apologize for being repetitive. Mainly we just wanted to make sure
we're correctly understanding how the OpenStack module and VCL are
interacting so we can be confident in any workarounds we use in the
meantime.
Camero
Hi Cameron,
You pointed the problem we've discussed in the JIRA issue (
https://issues.apache.org/jira/browse/VCL-590).
And you are right. Terminating an instance using the private IP could cause
that problem you described. The one of the main reason is the dnsmasq (dhcp
sever) that can change th
44 matches
Mail list logo
