On our CentOs 5.5 instance cloud-init --version returns "bad command
--version" on std error and has an exit code of 1. We know that this is
cloud-init version 0.6.3... So using to Popen to execute the call might not
give the desired result.
A quick check of the cloud-init code base seems to show that --version was
introduced in revision 564 in 2012-07-06, so works with cloud-init 0.7.0
onwards.
If the version check is to be preserved, one approach would be to use the
existing working (mostly) code: if that fails with the exception, then
retry via Popen. If that fails: well, two paths have been tried. I'm not
sure what more could be done.
Or alternately, given that we are talking about 2012, the alternate idea of
getting rid of the version checking sounds appealing. But then that's easy
for me to say, as I have no idea as to what might break if its removed...
On 6 August 2015 at 12:46, Steve Baker <email address hidden> wrote:
> On 06/08/15 12:42, Martin Paulo wrote:
> > Interestingly a command line call:
> > $ cloud-init --version
> > cloud-init 0.7.7
> It looks like the fix would be to Popen and execute "cloud-init
> --version" instead of getting it from python packaging, or just remove
> that version checking which was there to look for truly ancient versions
> of cloud-init (pre 0.6.0).
>
>
> ** Tags added: kilo-backport-potential
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1481614
>
> Title:
> Ubuntu 15.04 python3 path problem when running loguserdata.py
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/heat/+bug/1481614/+subscriptions
>
On our CentOs 5.5 instance cloud-init --version returns "bad command
--version" on std error and has an exit code of 1. We know that this is
cloud-init version 0.6.3... So using to Popen to execute the call might not
give the desired result.
A quick check of the cloud-init code base seems to show that --version was
introduced in revision 564 in 2012-07-06, so works with cloud-init 0.7.0
onwards.
If the version check is to be preserved, one approach would be to use the
existing working (mostly) code: if that fails with the exception, then
retry via Popen. If that fails: well, two paths have been tried. I'm not
sure what more could be done.
Or alternately, given that we are talking about 2012, the alternate idea of
getting rid of the version checking sounds appealing. But then that's easy
for me to say, as I have no idea as to what might break if its removed...
On 6 August 2015 at 12:46, Steve Baker <email address hidden> wrote:
> On 06/08/15 12:42, Martin Paulo wrote: potential /bugs.launchpad .net/bugs/ 1481614 /bugs.launchpad .net/heat/ +bug/1481614/ +subscriptions
> > Interestingly a command line call:
> > $ cloud-init --version
> > cloud-init 0.7.7
> It looks like the fix would be to Popen and execute "cloud-init
> --version" instead of getting it from python packaging, or just remove
> that version checking which was there to look for truly ancient versions
> of cloud-init (pre 0.6.0).
>
>
> ** Tags added: kilo-backport-
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> Ubuntu 15.04 python3 path problem when running loguserdata.py
>
> To manage notifications about this bug go to:
> https:/
>
-- ======= ======= ======= ======= ======= ======= ======= ======= ==
=======
Martin Paulo, BSc.
Software Developer
Tel : +61-3-9434 2508 (Home) www.thepaulofam ily.net
Tel : 04 205 20339 (Mobile)
Site: http://
"Nobody goes there any more. It's too crowded" - Yogi Berra.