Re: [openstack-dev] [heat] computed package names?
Excerpts from Zane Bitter's message of 2014-04-16 08:39:56 -0700: > On 16/04/14 05:53, Thomas Spatzier wrote: > > IMO, it would be desirable to not have things like yum or apt appear in the > > template explicitly. For many packages it seems like at least the top level > > package names (not including distro specific versioning strings) are equal > > across distros so when specified in a template it should be possible for a > > software deployment hook (which can be distro specific) to figure out how > > to install the package. > > I think this thread demonstrates the opposite: package names can be > different even among closely-related distributions (Fedora vs. RHEL) - > or even versions of the same distribution (Fedora 17 vs. 18). And while > Ubuntu is derived from Debian (and thus most apt packages are likely to > share package names), there's no reason whatsoever to expect e.g. > OpenSUSE to have the same package names as Fedora, despite both being > based on RPM. > > Brian Aker once suggested to me a scheme based on the path to the thing > you want installed: e.g. you request /usr/bin/httpd and the agent uses > "yum provides" or the apt equivalent to install the appropriate package. > That's an idea that might work better, although paths are by no means > standardised across distros either. Unfortunately that won't work for Ubuntu/Debian because they have /usr/bin/apache2. :-P With diskimage-builder, we've just been building a map of package names for each distro and using a script called 'install-package' to pull in packages using a single code base. We've also considered using bindep: https://github.com/stackforge/bindep But I'm not sure it will be generally consumable enough for this purpose. > > In any event, though, my impression is that we are trying to get out of > the cfn-init business as much as possible and leave the task to some > combination of custom images, software config and configuration > management. Hopefully someone will correct me if that impression is > inaccurate... > Right, I think that is probably the way to go long term. One large hole that leaves is post-boot updates, because OS::Heat::CloudConfig will only be actioned on first boot. But perhaps the right answer there is to move to a more powerful software management tool to support that case. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] computed package names?
On 16/04/14 21:53, Thomas Spatzier wrote: >> From: Zane Bitter >> To: openstack-dev@lists.openstack.org >> Date: 16/04/2014 00:46 >> Subject: Re: [openstack-dev] [heat] computed package names? >> >> On 15/04/14 17:59, Mike Spreitzer wrote: >>> Clint Byrum wrote on 04/15/2014 05:17:21 PM: >>> > Excerpts from Zane Bitter's message of 2014-04-15 13:32:30 -0700: >>> > >>> > > FWIW, in the short term I'm not aware of any issue with installing >>> > > mariadb in Fedora 17/18, provided that mysql is not installed >>> first. And >>> > > in fact they're both EOL anyway, so we should probably migrate all > the >>> > > templates to Fedora 20 and mariadb. >>> > >>> > +1 for that. >>> >>> I count 22 templates in heat-templates that are written to support >>> Fedora, Ubuntu, and RHEL; is MariaDB available in those? I do not see >>> it in Ubuntu 12.10, for example. >> I imagine it's a problem for RHEL (can RHEL 7 just get released >> already?). Ubuntu is not an issue though, unless they have adopted yum >> while I was not looking. >> >> Checking a random sample, they only includes "yum" and "systemd" >> sections (no "apt" or "sysvinit") in the metadata, so the purported >> support for Ubuntu 10.04 is just due to copy-paste and isn't actually >> implemented. > IMO, it would be desirable to not have things like yum or apt appear in the > template explicitly. For many packages it seems like at least the top level > package names (not including distro specific versioning strings) are equal > across distros so when specified in a template it should be possible for a > software deployment hook (which can be distro specific) to figure out how > to install the package. > Using software-config plus provider templates plus environments it is possible to write templates which are completely distro (and config method) agnostic. A separate environment file can be provided for every desired distro+config which defines resource types for the boot config and deployment config resources. The result is very tidy and maintainable. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] computed package names?
On 04/16/2014 09:24 AM, Fox, Kevin M wrote: Different distro's move the binaries and services too. ubuntu/debian does: /usr/sbin/apache2, not httpd. The service is also named apache2, not httpd. So, I think distro specific sets of packages are somewhat unavoidable. Now, this use case might be a good case for supporting: https://blueprints.launchpad.net/heat/+spec/intrinsics https://blueprints.launchpad.net/heat/+spec/aws-novalue Amazon finally caved in and implemented these. I think heat needs them too. Is it possible to implement those with the new plugin function framework? If so, I might be willing to take a stab at it if I can find a bit of time. Thanks, Kevin Kevin, There is a review in progress: https://review.openstack.org/#/c/84468/ butter up some popcorn and enjoy :) Regards -steve From: Zane Bitter [zbit...@redhat.com] Sent: Wednesday, April 16, 2014 8:39 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [heat] computed package names? On 16/04/14 05:53, Thomas Spatzier wrote: IMO, it would be desirable to not have things like yum or apt appear in the template explicitly. For many packages it seems like at least the top level package names (not including distro specific versioning strings) are equal across distros so when specified in a template it should be possible for a software deployment hook (which can be distro specific) to figure out how to install the package. I think this thread demonstrates the opposite: package names can be different even among closely-related distributions (Fedora vs. RHEL) - or even versions of the same distribution (Fedora 17 vs. 18). And while Ubuntu is derived from Debian (and thus most apt packages are likely to share package names), there's no reason whatsoever to expect e.g. OpenSUSE to have the same package names as Fedora, despite both being based on RPM. Brian Aker once suggested to me a scheme based on the path to the thing you want installed: e.g. you request /usr/bin/httpd and the agent uses "yum provides" or the apt equivalent to install the appropriate package. That's an idea that might work better, although paths are by no means standardised across distros either. In any event, though, my impression is that we are trying to get out of the cfn-init business as much as possible and leave the task to some combination of custom images, software config and configuration management. Hopefully someone will correct me if that impression is inaccurate... cheers, Zane. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] computed package names?
Hello,
A few folks give me some suggestion, and I followed it, it seems that the
problem is not solved yet, anyone can tell what steps here is not correct?
openstack@ubuntu:~$ keystone-manage db_sync
openstack@ubuntu:~$ openssl rand -hex 10
2c3a6bb5b3b8880f44f2
openstack@ubuntu:~$ sudo vi /etc/keystone/keystone.conf
[sudo] password for openstack:
openstack@ubuntu:~$ service keystone restart
stop: Rejected send message, 1 matched rules; type="method_call", sender=":1.6"
(uid=1000 pid=4110 comm="stop keystone ") interface="com.ubuntu.Upstart0_6.Job"
member="Stop" error name="(unset)" requested_reply="0"
destination="com.ubuntu.Upstart" (uid=0 pid=1 comm="/sbin/init")
start: Rejected send message, 1 matched rules; type="method_call",
sender=":1.7" (uid=1000 pid=4107 comm="start keystone ")
interface="com.ubuntu.Upstart0_6.Job" member="Start" error name="(unset)"
requested_reply="0" destination="com.ubuntu.Upstart" (uid=0 pid=1
comm="/sbin/init")
openstack@ubuntu:~$ sudo service keystone restart
keystone stop/waiting
keystone start/running, process 4116
openstack@ubuntu:~$ export OS_SERVICE_TOKEN=2c3a6bb5b3b8880f44f2
openstack@ubuntu:~$ export OS_SERVICE_ENDPOINT=http://controller:35357/v2.0
openstack@ubuntu:~$ keystone tenant-create --name=admin --description="Admin
Tenant"
An unexpected error prevented the server from fulfilling your request.
(ProgrammingError) (1146, "Table 'keystone.token' doesn't exist") 'SELECT
token.id AS token_id, token.expires AS token_expires, token.extra AS
token_extra, token.valid AS token_valid, token.user_id AS token_user_id,
token.trust_id AS token_trust_id \nFROM token \nWHERE token.id = %s'
('2c3a6bb5b3b8880f44f2',) (HTTP 500)
openstack@ubuntu:~$ sudo keystone tenant-create --name=admin
--description="Admin Tenant"
Expecting an auth URL via either --os-auth-url or env[OS_AUTH_URL]
Best Regards!
Min Wang
Software Engineer-Cloud Service
min.wa...@hp.com
-Original Message-
From: Fox, Kevin M [mailto:kevin@pnnl.gov]
Sent: Wednesday, April 16, 2014 9:25 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [heat] computed package names?
Different distro's move the binaries and services too. ubuntu/debian does:
/usr/sbin/apache2, not httpd. The service is also named apache2, not httpd.
So, I think distro specific sets of packages are somewhat unavoidable.
Now, this use case might be a good case for supporting:
https://blueprints.launchpad.net/heat/+spec/intrinsics
https://blueprints.launchpad.net/heat/+spec/aws-novalue
Amazon finally caved in and implemented these. I think heat needs them too.
Is it possible to implement those with the new plugin function framework? If
so, I might be willing to take a stab at it if I can find a bit of time.
Thanks,
Kevin
From: Zane Bitter [zbit...@redhat.com]
Sent: Wednesday, April 16, 2014 8:39 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [heat] computed package names?
On 16/04/14 05:53, Thomas Spatzier wrote:
> IMO, it would be desirable to not have things like yum or apt appear
> in the template explicitly. For many packages it seems like at least
> the top level package names (not including distro specific versioning
> strings) are equal across distros so when specified in a template it
> should be possible for a software deployment hook (which can be distro
> specific) to figure out how to install the package.
I think this thread demonstrates the opposite: package names can be different
even among closely-related distributions (Fedora vs. RHEL) - or even versions
of the same distribution (Fedora 17 vs. 18). And while Ubuntu is derived from
Debian (and thus most apt packages are likely to share package names), there's
no reason whatsoever to expect e.g.
OpenSUSE to have the same package names as Fedora, despite both being based on
RPM.
Brian Aker once suggested to me a scheme based on the path to the thing you
want installed: e.g. you request /usr/bin/httpd and the agent uses "yum
provides" or the apt equivalent to install the appropriate package.
That's an idea that might work better, although paths are by no means
standardised across distros either.
In any event, though, my impression is that we are trying to get out of the
cfn-init business as much as possible and leave the task to some combination of
custom images, software config and configuration management. Hopefully someone
will correct me if that impression is inaccurate...
cheers,
Zane.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mail
Re: [openstack-dev] [heat] computed package names?
Different distro's move the binaries and services too. ubuntu/debian does: /usr/sbin/apache2, not httpd. The service is also named apache2, not httpd. So, I think distro specific sets of packages are somewhat unavoidable. Now, this use case might be a good case for supporting: https://blueprints.launchpad.net/heat/+spec/intrinsics https://blueprints.launchpad.net/heat/+spec/aws-novalue Amazon finally caved in and implemented these. I think heat needs them too. Is it possible to implement those with the new plugin function framework? If so, I might be willing to take a stab at it if I can find a bit of time. Thanks, Kevin From: Zane Bitter [zbit...@redhat.com] Sent: Wednesday, April 16, 2014 8:39 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [heat] computed package names? On 16/04/14 05:53, Thomas Spatzier wrote: > IMO, it would be desirable to not have things like yum or apt appear in the > template explicitly. For many packages it seems like at least the top level > package names (not including distro specific versioning strings) are equal > across distros so when specified in a template it should be possible for a > software deployment hook (which can be distro specific) to figure out how > to install the package. I think this thread demonstrates the opposite: package names can be different even among closely-related distributions (Fedora vs. RHEL) - or even versions of the same distribution (Fedora 17 vs. 18). And while Ubuntu is derived from Debian (and thus most apt packages are likely to share package names), there's no reason whatsoever to expect e.g. OpenSUSE to have the same package names as Fedora, despite both being based on RPM. Brian Aker once suggested to me a scheme based on the path to the thing you want installed: e.g. you request /usr/bin/httpd and the agent uses "yum provides" or the apt equivalent to install the appropriate package. That's an idea that might work better, although paths are by no means standardised across distros either. In any event, though, my impression is that we are trying to get out of the cfn-init business as much as possible and leave the task to some combination of custom images, software config and configuration management. Hopefully someone will correct me if that impression is inaccurate... cheers, Zane. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] computed package names?
Zane Bitter wrote on 04/16/2014 11:39:56 AM: > In any event, though, my impression is that we are trying to get out of > the cfn-init business as much as possible and leave the task to some > combination of custom images, software config and configuration > management. Hopefully someone will correct me if that impression is > inaccurate... The circle is now complete. I set out to exercise the new software config work. I decided I would try to write software components and deployments to accomplish what is done in one of the templates found in heat-templates. I wanted to try a two-server WordPress example. I wanted to test the existing template. I found they were all using outdated images. I thought I would update an existing template --- which already appeared to allow a choice between many operating system releases --- to add support for something recent. I sent some questions about images under separate cover. Answers to those would break today's circle. Thanks, Mike___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] computed package names?
On 16/04/14 05:53, Thomas Spatzier wrote: IMO, it would be desirable to not have things like yum or apt appear in the template explicitly. For many packages it seems like at least the top level package names (not including distro specific versioning strings) are equal across distros so when specified in a template it should be possible for a software deployment hook (which can be distro specific) to figure out how to install the package. I think this thread demonstrates the opposite: package names can be different even among closely-related distributions (Fedora vs. RHEL) - or even versions of the same distribution (Fedora 17 vs. 18). And while Ubuntu is derived from Debian (and thus most apt packages are likely to share package names), there's no reason whatsoever to expect e.g. OpenSUSE to have the same package names as Fedora, despite both being based on RPM. Brian Aker once suggested to me a scheme based on the path to the thing you want installed: e.g. you request /usr/bin/httpd and the agent uses "yum provides" or the apt equivalent to install the appropriate package. That's an idea that might work better, although paths are by no means standardised across distros either. In any event, though, my impression is that we are trying to get out of the cfn-init business as much as possible and leave the task to some combination of custom images, software config and configuration management. Hopefully someone will correct me if that impression is inaccurate... cheers, Zane. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] computed package names?
+1 on porting the templates. What I would suggest also is to restructure the heat-templates directory layout. Most of the templates are not so different between OS distros. Besides this, what the heat-templates project really helps is that the templates are the best teaching materials for new users. Having them stored in sub-directories named by the OS distro is confusing. Maybe we can consider organize them like what we did for the test cases: - most templates are no more than demonstrating only one or two features; - a template may have a variant only when the changes needed for running on another OS distro are significant; - in template comments, the author is expected to record on which distros it has been tested; - there could be template groups that can be placed into a dedicated subdirectory -- the templates/scripts are supposed to be used together BTW, did I missed the conclusion from the 'heatr' discussion? Regards, Qiming On Wed, Apr 16, 2014 at 11:54:51AM +0200, Thomas Spatzier wrote: > > From: Steven Dake > > To: "OpenStack Development Mailing List (not for usage questions)" > > > > Date: 16/04/2014 01:43 > > Subject: Re: [openstack-dev] [heat] computed package names? > > > > On 04/15/2014 03:45 PM, Zane Bitter wrote: > > > On 15/04/14 17:59, Mike Spreitzer wrote: > > >> Clint Byrum wrote on 04/15/2014 05:17:21 PM: > > >> > Excerpts from Zane Bitter's message of 2014-04-15 13:32:30 -0700: > > >> > > > >> > > FWIW, in the short term I'm not aware of any issue with > installing > > >> > > mariadb in Fedora 17/18, provided that mysql is not installed > > >> first. And > > >> > > in fact they're both EOL anyway, so we should probably migrate > > >> all the > > >> > > templates to Fedora 20 and mariadb. > > >> > > > > > The last time I tried F17 images, the database installation step failed > > miserably because of problems in the base distribution. > > > > >> > +1 for that. > > >> > > >> I count 22 templates in heat-templates that are written to support > > >> Fedora, Ubuntu, and RHEL; is MariaDB available in those? I do not see > > >> it in Ubuntu 12.10, for example. > > > > > > I imagine it's a problem for RHEL (can RHEL 7 just get released > > > already?). Ubuntu is not an issue though, unless they have adopted yum > > > while I was not looking. > > > > > > Checking a random sample, they only includes "yum" and "systemd" > > > sections (no "apt" or "sysvinit") in the metadata, so the purported > > > support for Ubuntu 10.04 is just due to copy-paste and isn't actually > > > implemented. > > > > > > There is, I thought, one template that does actually support Ubuntu. > > > Stuff in the "F17" directory is there for a reason. > > > > > The only rational reason for having the F17 directory is because nobody > > has done the work of porting these templates to F20. That work needs to > > be done before we can remove the F17 directory permanently :) > > +1 on porting existing templates to current distros. And it would be even > better to start using some of the new features like software config. > I have actually started on a WordPress example that uses software config > and should be to post this for review soon. > > Regards, > Thomas > > > > > Regards, > > -steve > > > > > - ZB > > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] computed package names?
In the case of yum or apt package installation, I would recommend to give OS::Heat::CloudConfig a try, instead of sticking to cfn-init. The function you proposed (Fn::MemberListToMap) actually brings us back to the previous discussion whether a mapping section is really needed in the native HOT template. My understanding was that people are more inclined to use provider templates for this kind of varieties or flexibilities. I am still feeling that we need a simple, intuitive, declarative way to specify maps/dicts for convenience. Provider templates, IMHO, are too heavy-weight for this. However, for keys, I don't know whether it is a good idea to make it a variable. Regards, Qiming On Tue, Apr 15, 2014 at 06:15:36PM -0400, Mike Spreitzer wrote: > Mike Spreitzer/Watson/IBM@IBMUS wrote on 04/15/2014 05:59:50 PM: > > > Yes, I can see how OS::Heat::Init makes sense. But is this just the > > first thing on a long list? Would it be better to have a static > > intrinsic that is like Python's dict(iterable of > > iterable)->dictionary function? > > .. and I see now that we do: Fn::MemberListToMap > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] computed package names?
On 04/16/2014 02:53 AM, Thomas Spatzier wrote: From: Zane Bitter To: openstack-dev@lists.openstack.org Date: 16/04/2014 00:46 Subject: Re: [openstack-dev] [heat] computed package names? On 15/04/14 17:59, Mike Spreitzer wrote: Clint Byrum wrote on 04/15/2014 05:17:21 PM: > Excerpts from Zane Bitter's message of 2014-04-15 13:32:30 -0700: > > > FWIW, in the short term I'm not aware of any issue with installing > > mariadb in Fedora 17/18, provided that mysql is not installed first. And > > in fact they're both EOL anyway, so we should probably migrate all the > > templates to Fedora 20 and mariadb. > > +1 for that. I count 22 templates in heat-templates that are written to support Fedora, Ubuntu, and RHEL; is MariaDB available in those? I do not see it in Ubuntu 12.10, for example. I imagine it's a problem for RHEL (can RHEL 7 just get released already?). Ubuntu is not an issue though, unless they have adopted yum while I was not looking. Checking a random sample, they only includes "yum" and "systemd" sections (no "apt" or "sysvinit") in the metadata, so the purported support for Ubuntu 10.04 is just due to copy-paste and isn't actually implemented. IMO, it would be desirable to not have things like yum or apt appear in the template explicitly. For many packages it seems like at least the top level package names (not including distro specific versioning strings) are equal across distros so when specified in a template it should be possible for a software deployment hook (which can be distro specific) to figure out how to install the package. The package names are different for different distros. The most basic example is the web server (Debian is apache2, RPM is httpd). I'm not sure exactly how to rectify the fact that they are different with while keeping the top level metadata blob that describes which packages to install limited to one distro. Regards -steve Regards, Thomas There is, I thought, one template that does actually support Ubuntu. Stuff in the "F17" directory is there for a reason. - ZB ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] computed package names?
> From: Zane Bitter > To: openstack-dev@lists.openstack.org > Date: 16/04/2014 00:46 > Subject: Re: [openstack-dev] [heat] computed package names? > > On 15/04/14 17:59, Mike Spreitzer wrote: > > Clint Byrum wrote on 04/15/2014 05:17:21 PM: > > > Excerpts from Zane Bitter's message of 2014-04-15 13:32:30 -0700: > > > > > > > FWIW, in the short term I'm not aware of any issue with installing > > > > mariadb in Fedora 17/18, provided that mysql is not installed > > first. And > > > > in fact they're both EOL anyway, so we should probably migrate all the > > > > templates to Fedora 20 and mariadb. > > > > > > +1 for that. > > > > I count 22 templates in heat-templates that are written to support > > Fedora, Ubuntu, and RHEL; is MariaDB available in those? I do not see > > it in Ubuntu 12.10, for example. > > I imagine it's a problem for RHEL (can RHEL 7 just get released > already?). Ubuntu is not an issue though, unless they have adopted yum > while I was not looking. > > Checking a random sample, they only includes "yum" and "systemd" > sections (no "apt" or "sysvinit") in the metadata, so the purported > support for Ubuntu 10.04 is just due to copy-paste and isn't actually > implemented. IMO, it would be desirable to not have things like yum or apt appear in the template explicitly. For many packages it seems like at least the top level package names (not including distro specific versioning strings) are equal across distros so when specified in a template it should be possible for a software deployment hook (which can be distro specific) to figure out how to install the package. Regards, Thomas > > There is, I thought, one template that does actually support Ubuntu. > Stuff in the "F17" directory is there for a reason. > > - ZB > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] computed package names?
> From: Steven Dake > To: "OpenStack Development Mailing List (not for usage questions)" > > Date: 16/04/2014 01:43 > Subject: Re: [openstack-dev] [heat] computed package names? > > On 04/15/2014 03:45 PM, Zane Bitter wrote: > > On 15/04/14 17:59, Mike Spreitzer wrote: > >> Clint Byrum wrote on 04/15/2014 05:17:21 PM: > >> > Excerpts from Zane Bitter's message of 2014-04-15 13:32:30 -0700: > >> > > >> > > FWIW, in the short term I'm not aware of any issue with installing > >> > > mariadb in Fedora 17/18, provided that mysql is not installed > >> first. And > >> > > in fact they're both EOL anyway, so we should probably migrate > >> all the > >> > > templates to Fedora 20 and mariadb. > >> > > > The last time I tried F17 images, the database installation step failed > miserably because of problems in the base distribution. > > >> > +1 for that. > >> > >> I count 22 templates in heat-templates that are written to support > >> Fedora, Ubuntu, and RHEL; is MariaDB available in those? I do not see > >> it in Ubuntu 12.10, for example. > > > > I imagine it's a problem for RHEL (can RHEL 7 just get released > > already?). Ubuntu is not an issue though, unless they have adopted yum > > while I was not looking. > > > > Checking a random sample, they only includes "yum" and "systemd" > > sections (no "apt" or "sysvinit") in the metadata, so the purported > > support for Ubuntu 10.04 is just due to copy-paste and isn't actually > > implemented. > > > > There is, I thought, one template that does actually support Ubuntu. > > Stuff in the "F17" directory is there for a reason. > > > The only rational reason for having the F17 directory is because nobody > has done the work of porting these templates to F20. That work needs to > be done before we can remove the F17 directory permanently :) +1 on porting existing templates to current distros. And it would be even better to start using some of the new features like software config. I have actually started on a WordPress example that uses software config and should be to post this for review soon. Regards, Thomas > > Regards, > -steve > > > - ZB > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] computed package names?
On 04/15/2014 03:45 PM, Zane Bitter wrote: On 15/04/14 17:59, Mike Spreitzer wrote: Clint Byrum wrote on 04/15/2014 05:17:21 PM: > Excerpts from Zane Bitter's message of 2014-04-15 13:32:30 -0700: > > > FWIW, in the short term I'm not aware of any issue with installing > > mariadb in Fedora 17/18, provided that mysql is not installed first. And > > in fact they're both EOL anyway, so we should probably migrate all the > > templates to Fedora 20 and mariadb. > The last time I tried F17 images, the database installation step failed miserably because of problems in the base distribution. > +1 for that. I count 22 templates in heat-templates that are written to support Fedora, Ubuntu, and RHEL; is MariaDB available in those? I do not see it in Ubuntu 12.10, for example. I imagine it's a problem for RHEL (can RHEL 7 just get released already?). Ubuntu is not an issue though, unless they have adopted yum while I was not looking. Checking a random sample, they only includes "yum" and "systemd" sections (no "apt" or "sysvinit") in the metadata, so the purported support for Ubuntu 10.04 is just due to copy-paste and isn't actually implemented. There is, I thought, one template that does actually support Ubuntu. Stuff in the "F17" directory is there for a reason. The only rational reason for having the F17 directory is because nobody has done the work of porting these templates to F20. That work needs to be done before we can remove the F17 directory permanently :) Regards, -steve - ZB ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] computed package names?
On 15/04/14 17:59, Mike Spreitzer wrote: Clint Byrum wrote on 04/15/2014 05:17:21 PM: > Excerpts from Zane Bitter's message of 2014-04-15 13:32:30 -0700: > > > FWIW, in the short term I'm not aware of any issue with installing > > mariadb in Fedora 17/18, provided that mysql is not installed first. And > > in fact they're both EOL anyway, so we should probably migrate all the > > templates to Fedora 20 and mariadb. > > +1 for that. I count 22 templates in heat-templates that are written to support Fedora, Ubuntu, and RHEL; is MariaDB available in those? I do not see it in Ubuntu 12.10, for example. I imagine it's a problem for RHEL (can RHEL 7 just get released already?). Ubuntu is not an issue though, unless they have adopted yum while I was not looking. Checking a random sample, they only includes "yum" and "systemd" sections (no "apt" or "sysvinit") in the metadata, so the purported support for Ubuntu 10.04 is just due to copy-paste and isn't actually implemented. There is, I thought, one template that does actually support Ubuntu. Stuff in the "F17" directory is there for a reason. - ZB ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] computed package names?
Excerpts from Mike Spreitzer's message of 2014-04-15 14:59:50 -0700: > Clint Byrum wrote on 04/15/2014 05:17:21 PM: > > > Excerpts from Zane Bitter's message of 2014-04-15 13:32:30 -0700: > > > > Yes, that _kind_ of thing. But I don't see much point in having an > > > AWS::CloudFormation::Init section that isn't compatible with > > > CloudFormation's definition of it. We already have some native > > > in-instance tools (e.g. os-apply-config) that can probably handle this > > > > better. > > > > > > > os-apply-config wouldn't really be what you want. It is specifically > > only intended for translating communication values into configuration. > > Package installation is not handled. > > > > We don't have a native declarative post-boot package installation > > tool that can be expressed this way. If you must do vanilla images + > > customization, I think cfn-init is generally fine. This particular case, > > however, shows a place where they abused the mapping json type pretty > > badly. I think it would make sense to have a native OS::Heat::Init > > section that takes the package name as a value or something. > > > > > FWIW, in the short term I'm not aware of any issue with installing > > > mariadb in Fedora 17/18, provided that mysql is not installed first. > And > > > in fact they're both EOL anyway, so we should probably migrate all the > > > > templates to Fedora 20 and mariadb. > > > > +1 for that. > > I count 22 templates in heat-templates that are written to support Fedora, > Ubuntu, and RHEL; is MariaDB available in those? I do not see it in > Ubuntu 12.10, for example. > No, MariaDB might be in Ubuntu 14.04.. haven't checked, but mysql is still the recommended one. > Those templates support ubuntu 10. Just 10! It will probably be easiest > to add Ubuntu 12 (as in 12.04 LTS) and 14 (as in 14.04 LTS). > Ubuntu 10.04 has just 1 year of support left. Time to start migrating! :) > Yes, I can see how OS::Heat::Init makes sense. But is this just the first > thing on a long list? Would it be better to have a static intrinsic that > is like Python's dict(iterable of iterable)->dictionary function? > Yes I don't know what the python thing you're referring to is. Yes, it is the first in the list of things we'd change while creating a native format. Though another option is to just adopt external tools like puppet/chef/salt to do this. We creates os-*-config in TripleO so we didn't have to pick a religion and so that we could do "the unix way" and make tools that only do one thing. However, for template examples, it might be a little easier to accept one religion, er, tool, in one template, and another tool in a different template. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] computed package names?
Mike Spreitzer/Watson/IBM@IBMUS wrote on 04/15/2014 05:59:50 PM: > Yes, I can see how OS::Heat::Init makes sense. But is this just the > first thing on a long list? Would it be better to have a static > intrinsic that is like Python's dict(iterable of > iterable)->dictionary function? .. and I see now that we do: Fn::MemberListToMap ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] computed package names?
Clint Byrum wrote on 04/15/2014 05:17:21 PM: > Excerpts from Zane Bitter's message of 2014-04-15 13:32:30 -0700: > > Yes, that _kind_ of thing. But I don't see much point in having an > > AWS::CloudFormation::Init section that isn't compatible with > > CloudFormation's definition of it. We already have some native > > in-instance tools (e.g. os-apply-config) that can probably handle this > > better. > > > > os-apply-config wouldn't really be what you want. It is specifically > only intended for translating communication values into configuration. > Package installation is not handled. > > We don't have a native declarative post-boot package installation > tool that can be expressed this way. If you must do vanilla images + > customization, I think cfn-init is generally fine. This particular case, > however, shows a place where they abused the mapping json type pretty > badly. I think it would make sense to have a native OS::Heat::Init > section that takes the package name as a value or something. > > > FWIW, in the short term I'm not aware of any issue with installing > > mariadb in Fedora 17/18, provided that mysql is not installed first. And > > in fact they're both EOL anyway, so we should probably migrate all the > > templates to Fedora 20 and mariadb. > > +1 for that. I count 22 templates in heat-templates that are written to support Fedora, Ubuntu, and RHEL; is MariaDB available in those? I do not see it in Ubuntu 12.10, for example. Those templates support ubuntu 10. Just 10! It will probably be easiest to add Ubuntu 12 (as in 12.04 LTS) and 14 (as in 14.04 LTS). Yes, I can see how OS::Heat::Init makes sense. But is this just the first thing on a long list? Would it be better to have a static intrinsic that is like Python's dict(iterable of iterable)->dictionary function? Thanks, Mike___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] computed package names?
Excerpts from Zane Bitter's message of 2014-04-15 13:32:30 -0700:
> On 15/04/14 15:57, Mike Spreitzer wrote:
> > Zane Bitter wrote on 04/15/2014 03:29:03 PM:
> >
> > > On 15/04/14 14:31, Mike Spreitzer wrote:
> > > > It appears that in Fedora 19 and 20 the Wordpress examples need to
> > > > install different packages than in every other release (see my
> > debugging
> > > > in https://review.openstack.org/#/c/87065/). I just got a complaint
> > > > from Heat validation that I can't do this:
> > > >
> > > > "AWS::CloudFormation::Init" : {
> > > >"config" : {
> > > > "packages" : {
> > > >"yum" : {
> > > > { "Fn::FindInMap" : [ "Pkgset2Pkgs", { "Fn::FindInMap" : [
> > > > "Distro2Pkgset", { "Ref" : "LinuxDistribution" }, "db" ] },
> > "client" ] }
> > > > : [],
> > > > { "Fn::FindInMap" : [ "Pkgset2Pkgs", { "Fn::FindInMap" : [
> > > > "Distro2Pkgset", { "Ref" : "LinuxDistribution" }, "db" ] },
> > "server" ] }
> > > > : [],
> > > >
> > >
> > > .. in
> > > JSON a property name cannot be an object ...
> >
> > Ah, right. So what would be the simplest way to enable this use case?
> > Perhaps a generalization of AWS::CloudFormation::Init that allows the
> > package names to be objects (that evaluate to strings, of course)?
> > Maybe allow, e.g., "yum" to be associated with not a map but rather a
> > list of pairs (2-element lists)?
>
> Yes, that _kind_ of thing. But I don't see much point in having an
> AWS::CloudFormation::Init section that isn't compatible with
> CloudFormation's definition of it. We already have some native
> in-instance tools (e.g. os-apply-config) that can probably handle this
> better.
>
os-apply-config wouldn't really be what you want. It is specifically
only intended for translating communication values into configuration.
Package installation is not handled.
We don't have a native declarative post-boot package installation
tool that can be expressed this way. If you must do vanilla images +
customization, I think cfn-init is generally fine. This particular case,
however, shows a place where they abused the mapping json type pretty
badly. I think it would make sense to have a native OS::Heat::Init
section that takes the package name as a value or something.
> FWIW, in the short term I'm not aware of any issue with installing
> mariadb in Fedora 17/18, provided that mysql is not installed first. And
> in fact they're both EOL anyway, so we should probably migrate all the
> templates to Fedora 20 and mariadb.
+1 for that.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] computed package names?
On 15/04/14 15:57, Mike Spreitzer wrote:
Zane Bitter wrote on 04/15/2014 03:29:03 PM:
> On 15/04/14 14:31, Mike Spreitzer wrote:
> > It appears that in Fedora 19 and 20 the Wordpress examples need to
> > install different packages than in every other release (see my
debugging
> > in https://review.openstack.org/#/c/87065/). I just got a complaint
> > from Heat validation that I can't do this:
> >
> > "AWS::CloudFormation::Init" : {
> >"config" : {
> > "packages" : {
> >"yum" : {
> > { "Fn::FindInMap" : [ "Pkgset2Pkgs", { "Fn::FindInMap" : [
> > "Distro2Pkgset", { "Ref" : "LinuxDistribution" }, "db" ] },
"client" ] }
> > : [],
> > { "Fn::FindInMap" : [ "Pkgset2Pkgs", { "Fn::FindInMap" : [
> > "Distro2Pkgset", { "Ref" : "LinuxDistribution" }, "db" ] },
"server" ] }
> > : [],
> >
>
> .. in
> JSON a property name cannot be an object ...
Ah, right. So what would be the simplest way to enable this use case?
Perhaps a generalization of AWS::CloudFormation::Init that allows the
package names to be objects (that evaluate to strings, of course)?
Maybe allow, e.g., "yum" to be associated with not a map but rather a
list of pairs (2-element lists)?
Yes, that _kind_ of thing. But I don't see much point in having an
AWS::CloudFormation::Init section that isn't compatible with
CloudFormation's definition of it. We already have some native
in-instance tools (e.g. os-apply-config) that can probably handle this
better.
FWIW, in the short term I'm not aware of any issue with installing
mariadb in Fedora 17/18, provided that mysql is not installed first. And
in fact they're both EOL anyway, so we should probably migrate all the
templates to Fedora 20 and mariadb.
cheers,
Zane.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] computed package names?
Zane Bitter wrote on 04/15/2014 03:29:03 PM:
> On 15/04/14 14:31, Mike Spreitzer wrote:
> > It appears that in Fedora 19 and 20 the Wordpress examples need to
> > install different packages than in every other release (see my
debugging
> > in https://review.openstack.org/#/c/87065/). I just got a complaint
> > from Heat validation that I can't do this:
> >
> > "AWS::CloudFormation::Init" : {
> >"config" : {
> > "packages" : {
> >"yum" : {
> > { "Fn::FindInMap" : [ "Pkgset2Pkgs", { "Fn::FindInMap" : [
> > "Distro2Pkgset", { "Ref" : "LinuxDistribution" }, "db" ] }, "client" ]
}
> > : [],
> > { "Fn::FindInMap" : [ "Pkgset2Pkgs", { "Fn::FindInMap" : [
> > "Distro2Pkgset", { "Ref" : "LinuxDistribution" }, "db" ] }, "server" ]
}
> > : [],
> >
>
> .. in
> JSON a property name cannot be an object ...
Ah, right. So what would be the simplest way to enable this use case?
Perhaps a generalization of AWS::CloudFormation::Init that allows the
package names to be objects (that evaluate to strings, of course)? Maybe
allow, e.g., "yum" to be associated with not a map but rather a list of
pairs (2-element lists)?
Thanks,
Mike___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] computed package names?
On 15/04/14 14:31, Mike Spreitzer wrote:
It appears that in Fedora 19 and 20 the Wordpress examples need to
install different packages than in every other release (see my debugging
in https://review.openstack.org/#/c/87065/). I just got a complaint
from Heat validation that I can't do this:
"AWS::CloudFormation::Init" : {
"config" : {
"packages" : {
"yum" : {
{ "Fn::FindInMap" : [ "Pkgset2Pkgs", { "Fn::FindInMap" : [
"Distro2Pkgset", { "Ref" : "LinuxDistribution" }, "db" ] }, "client" ] }
: [],
{ "Fn::FindInMap" : [ "Pkgset2Pkgs", { "Fn::FindInMap" : [
"Distro2Pkgset", { "Ref" : "LinuxDistribution" }, "db" ] }, "server" ] }
: [],
because "expecting property name" at the place where the first {
"Fn::FindInMap" ... } appears. Am I understanding this right? Is there
a workable way to solve this problem?
The formatting of that config section is somewhat bizarre, and
unfortunately leaves no workable way to solve this problem because in
JSON a property name cannot be an object just as in Python a dict key
cannot be a dict.
cheers,
Zane.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
